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SECTION  1 

INTRODUCTION  AND  OVERVIEW 


1.1  GENERAL 

The  purpose  of  this  document  is  to  provide  the  user  with  an  over¬ 
view  of  the  TRACE  simulation  and  a  detailed  description  of  how  to  run  it. 
TRACE  is  currently  undergoing  further  development  to  enhance  the  simulation 
of  communications  equipment,  nuclear  effects,  and  logistics.  Although  a 
significant  amount  of  design  work  has  been  accomplished,  the  new  inputs  and 
outputs  related  to  these  enhancements  have  not  yet  been  installed.  There¬ 
fore,  this  manual  will  be  concerned  only  with  the  existing  version  of  TRACE 
which  is  installed  and  running  at  the  Air  Force  Weapons  Lab  (AFWL). 

This  chapter  will  present  some  background  information  and 
describe  key  characteristics  of  TRACE.  The  following  chapters  will  discuss 
the  inputs  to  the  simulation,  the  job  control  language  necessary  to  run  the 
simulation,  and  the  outputs  from  the  simulation. 

1 . 2  BACKGROUND 

TRACE  is  a  theater  level  tactical  combat  simulation  with  emphasis 
on  the  communications  aspects.  It  is  being  designed  and  developed  at  BDM 
for  the  Defense  Nuclear  Agency.  The  origins  of  TRACE  lie  in  the  TCOR  and 
COMBAT  II  simulations  also  developed  for  DNA  by  BDM  to  study  conventional 
and  nuclear  operations  at  the  theater  level.  The  application  of  COMBAT  II 
was  limited  by  its  high  level  of  aggregation,  confinement  of  ground  force 
maneuvers  to  one  dimension,  and  idealization  of  command  and  control 
processes.  The  development  of  TCOR  was  initiated  to  correct  these  and 
other  deficiencies.  TRACE  extends  TCOR  to  represent  and  study  communica¬ 
tions  in  greater  detail.  Many  key  ideas  came  from  a  preliminary  design 
study  for  a  Combined  Arms  Simulation  Model  (CASM)  which  BDM  performed  for 
the  USAF  (AF/SA).  This  study  utilized  the  concept  of  a  hexagonal  grid  to 
provide  for  two-dimensional  movement  of  ground  forces  and  developed 
concepts  for  much  improved  software  using  top-down  structured  programming 
techniques.  The  feasibility  of  these  concepts  was  demonstrated  by  the 
development  of  TCOR  I  for  DNA. 
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The  work  on  TCOR  I  has  spawned  a  new  generation  of  combat  simula¬ 
tions,  known  as  the  METRIC  family  of  simulations,  under  continuing  deve' ce¬ 
ment  and  utilization  at  8DM.  These  simulations  are  centered  on  players 
which  represent  decision-making  force  elements.  This  type  of  structure 
permits  operational ly  recognizable  battlefield  situations  and  interactions. 
Actions  and  their  consequences  are  explicitly  simulated  instead  of 
implicitly  contained  in  numerous  equations.  Mental  and  physical  processes 
are  separated  to  provide  a  distinction  between  actual  com1,  it  situations  and 
possibly  incomplete  or  inaccurate  perceptions  of  the  .•  tuations.  This 
permits  a  more  realistic  treatment  of  command,  control,  and  intelligence 
processes.  The  use  of  a  hexagonal  coordinate  system  allows  two-dimensional 
maneuver  of  ground  combat  units  thereby  improving  the  realism  of  unit 
interactions.  A  man- in-the- loop  capability  permits  tne  user  to  specify 
operations  orders  for  higher  level  command  units  and  thus  interact  directly 
with  the  simulation. 

A  brief  summary  of  the  members  of  the  METRIC  family  of  simula¬ 
tions  follows.  They  span  a  hierarchy  from  detailed  AAA  gun  vs.  aircraft  up 
through  a  theater  level  perspective.  TRACE  is  currently  a  descendent  of 
TCOR  evolving  from  a  version  that  lies  between  TCOR  I I A  and  the  completion 
of  TCOR  I  IB. 

Table  1.  Summary  of  METRIC  family  simulations. 

THE  METRIC  FAMILY  OF  SIMULATIONS 
(Oecember  1978) 

A  simulation  test  bed  developed  to  demonstrate  software  and 
modeling  concepts  of  the  METRIC  Family. 

An  extension  of  TCOR  I  to  represent  corps  level  electronic 
warfare  operations.  Emphasis  on  value  of  ESM  to  corps  and 
division  maneuver  planning.  Combat  interactions  resolved  at 
brigade/regiment  level.  All  command  and  control  accomp¬ 
lished  by  man- in-the- loop  means. 


TCOR  I 

CLEW  I 


8 


•*r**w~*m m  w  'w 


rrgSBBgS=*r-- 


l  U*L 


CLEW  II 

TCOR  II  A 

WARRANT 

TRACE 

INWARS 

MAOEM 

TAC  REPELLER/ 
TAC  GUNNER 

TCOR  II  3 


An  enhancement  of  CLEW  I  to  include  non-ESM  airborne  and 
groundbased  sensors.  Combat  interactions  resolved  at 
battal ion  level . 

Initial  stage  of  TCOR  development  intended  to  support 
analyses.  Principal  empnasis  on  ground  maneuver  and  fire 
support  operations  within  a  detailed  corps  area  where  combat 
interactions  are  resolved  at  company/battery  level.  Command 
and  control  by  man- i n-the-  1  oop  at  corps  level  and  oy  auto¬ 
mated  means  at  lower  echelons. 

An  application  of  TCOR  II  A  (detailed  corps)  simulation 
enhanced  to  include  Red  electronic  warfare  operations 
against  Blue  communication  networks. 

An  application  of  TCOR  II  enhanced  to  include  detailed 
representation  of  communications  and  their  vulnerability  to 
nuclear  weapons  effects,  in  particular  EMP.  TRACE  includes 
the  EW  operations  of  WARRANT. 

A  simulation  of  integrated  theater  level  nuclear,  chemical, 
and  conventional  warfare  under  development  for  the  U.S.  A-my 
Focus  is  on  command  and  control  processes  at  division  and 
above.  Combat  interactions  will  be  resolved  at  the  brigade/ 
regiment  level . 

A  detailed  simulation  of  Blue  area  air  defense  systems 
engaging  penetrating  Red  aircraft.  Resolution  is  at  the 
aircraft  flight  and  SAM  battery  level. 

Highly  detailed  simulations  of  Red  air  defense  systems 
engaging  penetrating  Blue  aircraft.  Resolution  is  at  the 

individual  aircraft  vs.  individual  missile/gu.;  level. 

An  extension  of  TCOR  II  A  in  development  to  include  enhance¬ 
ment  of  nuclear  effects,  logistics,  air  operations,  target 
acquisition,  and  weapons  assignment  processes. 
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DESCRIPTION  OF  THE  SIMULATION 

TRACE  is  designed  to  simulate  a  theater  level  combined  conven¬ 
tional  and  nuclear  conflict  between  NATO  and  WARSAW  PACT  forces  in  Central 
Europe.  The  specific  scenario,  including  the  command  and  control  struc¬ 
ture,  unit  descriptions,  weapon  system  characteristics,  and  operations 
orders  is  input  by  the  user. 

TRACE  has  the  capability  to  simulate  a  variety  of  military 
operations  including  meeting  engagements  and  breakthroughs.  The  user, 
acting  as  a  man- in- the- loop,  inputs  the  type  of  operation  as  well  as 
detailed  operations  orders  for  higher  level  commanders.  The  simulation 
then  adapts  and  refines  these  orders  for  each  lower  level  of  command. 

The  lowest  level  of  command  represented  in  TRACE  is  the 
battalion,  with  its  resources  distributed  among  a  number  of  company 
centers,  one  of  which  is  a  headquarters  company.  Higher  levels  of  command 
are  represented  explicitly  by  subordinate  headquarters  companies.  Company 
level  units  move  and  engage  in  combat  in  response  to  the  local  combat 
situation  and  orders  from  their  commanders.  The  movement  and  resources  of 
a  command  unit  are  calculated  by  aggregating  the  movement  and  resources  of 
subordinates. 

Company  level  units  are  characterized  by  the  number  of  radios, 
tanks,  artillery  tubes,  APC's  (ATU's),  and  ammunition  they  possess.  These 
factors  attribute  to  the  unit  some  capability  to  communicate,  move,  shoot, 
and  observe  its  surroundings.  By  varying  this  input,  the  user  can  repre¬ 
sent  various  types  of  mechanized  infantry,  armored  cavalry,  armor,  or 
artillery  units. 

Combat  support  is  represented  explicitly  by  artillery  units, 
electronic  warfare  (EW)  units,  and  close  air  support  (CAS).  Currently, 
tactical  air  missions,  other  than  close  air  support,  are  treated  implicitly 
to  determine  the  level  of  CAS  provided. 

Communications  can  be  simulated  at  two  different  levels  of 
detail,  depending  on  user  input.  Several  distinct  types  of  nets  are  repre¬ 
sented.  Message  types  include  operations  orders,  status  reports,  intelli¬ 
gence  reports,  close  air  support  requests,  and  artillery  support  requests. 
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EW  contermeasures  against  communications,  including  jamming,  direction 
finding,  and  signal  intelligence  can  also  be  simulated.  Communications 
passes  between  the  command  levels  and  affects  the  actions  of  the  units  at 
these  levels. 

Each  command  level  in  TRACE  is  capable  of  both  mental  and  physi¬ 
cal  processes.  Command  units  make  decisions  based  on  their  perceptions  of 
the  combat  situation.  These  perceptions  need  not  be  in  full  agreement  with 
the  actua.  situation.  Each  ground  unit,  through  its  own  sensors  and 
through  direct  observation  of  ground  movement  and  combat,  collects  informa¬ 
tion  on  enemy  forces  in  the  area.  This  information  may  be  used  within  the 
unit  and  also  transmitted  via  a  communications  network  to  higher 

commanders. 

TRACE  uses  a  stochastic  representation  of  critical  processes  to 
reflect  the  inherent  uncertainty  in  combat  interactions.  Users  desiring  to 
analyze  a  range  of  possible  outcomes  have  two  alternatives.  One  is  to 

resimulate  the  same  scenario  with  a  different  random  seed  to  generate 
different  random  draws.  The  other  possibility  is  to  make  slight  variations 
in  the  initial  or  subsequent  operations  orders  input  by  the  man-in-the-loop. 
1.4  SIMULATION  ARCHITECTURE 

The  TRACE  simulation  has  been  implemented  using  the  latest  tech¬ 
niques  of  top-down  structured  programming.  This  approach  makes  for  a 

logical  and  coherent  architecture  which  facilitates  the  design  and  develop¬ 
ment  process.  The  modularity  in  structure  also  simplifies  the  introduction 
of  improvements  and  modifications. 

The  design  of  TRACE  is  based  on  the  philosophy  that  the  decision¬ 
making  units  described  in  the  scenario  are  the  driving  factors,  rather  than 
the  processes  they  perform.  These  units  are  called  players  and  therefore 
the  simulation  is  called  player-centered.  All  units  at  the  battalion  level 
of  command  and  higher  are  players,  whereas  company  level  units  have  a  more 
limited  decision-making  capability  and  are  called  pseudo-players.  TRACE 
deals  with  the  interactions  of  players,  and  this  is  reflected  in  the  input. 
Instead  of  diverse  coefficients  for  arrays  of  equations,  the  primary  inputs 
consist  of  command  and  control  and  unit  descriptions. 
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The  processes  by  which  players  interact  in  TRACE  are  broken  down 
into  events.  An  event  represents  some  change  in  the  overall  status  of  the 
simulation  which  occurs  at  an  instantaneous  point  in  time  or  over  a  small 
incremental  time  step.  Some  events  are  discrete  and  occur  just  once  after 
being  scheduled,  while  others  are  continuous  and  occur  repeatedly  at  fixed 
time  intervals  from  the  time  they  are  scheduled  until  they  are  cancelled. 
Players  interact  by  scheduling  events  for  themselves  or  other  players. 
Corresponding  to  each  event,  there  are  one  or  more  subroutines  which  simu¬ 
late  it. 

Another  characteristic  of  the  philosophy  behind  TRACE  is  stimuli- 
driven  reactions  or  action-reaction  dynamics.  This  simply  means  that 
certain  processes  will  be  simulated  only  in  response  to  specific  actions  or 
stimuli  which  trigger  the  processes.  This  concept  is  implemented  through 
the  event  structure,  which  causes  new  events  to  be  scheduled  during  the 
simulation  of  a  given  event.  For  example,  if  a  player  is  not  in  range  of 
any  enemy  units,  no  combat  event  will  be  scheduled  for  him.  Suppose, 
however,  that  an  enemy  unit  moves  into  range.  As  the  movement  is  simu¬ 
lated,  an  event  corresponding  to  a  possible  observation  of  the  enemy  unit 
will  be  scheduled  for  the  player.  In  response  to  an  observation,  the 
player  may  decide  to  engage  the  enemy  unit  in  combat  and  schedule  a  combat 
event  for  himself.  This  approach  makes  the  simulation  execution  consid¬ 
erably  more  efficient  than  it  would  be  if  all  possible  processes  were 
executed  for  each  player  at  constant  time  intervals.  In  addition,  the 
design  process  is  simplified.  The  designer  can  restrict  his  attention  to 
one  small  section  of  each  process  at  a  time  by  listing  all  possible 
reactions  to  a  given  event  and  then  defining  new  events  corresponding  to 
those  reactions  whose  explicit  simulation  is  appropriate  to  the  overall 
level  of  detai 1 . 

All  of  the  data  which  defines  the  current  status  of  a  TRACE 
simulation  is  maintained  in  a  dynamically  allocated  storage  array.  Various 
types  of  data  structures,  linked  together  by  pointers,  record  unit  status, 
command  and  control  relationships,  future  events  which  have  been  scheduled, 
operations  orders,  material  strengths  and  losses,  messages  in  transit. 


perceptions  of  enemy  units,  targets  acquired,  weapons  allocated,  etc. 
Numerous  list  processing  routines  add  or  delete  blocks  from  specific  lists, 
acquiring  or  releasing  storage  space,  as  the  simulation  progresses. 

The  TRACE  simulation  is  driven  by  a  set  of  subroutines  called  the 
Simulation  Control  Software  (SCS).  The  SCS  maintains  the  dynamically 
allocated  storage  array,  sorts  discrete  events  by  the  time  they  are  to  be 
simulated,  sorts  continuous  events  by  their  time  intervals,  and  calls  the 
event  processing  modules  in  the  proper  sequence.  Thus,  the  SCS  serves  as  a 
storage  manager  and  a  time-keeper.  No  event  processing  can  De  initiated 
except  through  the  SCS.  This  requirement  has  the  effect  of  decoupling  the 
interactions  between  units  and  enforcing  the  modular  structure  of  the  code. 
If  one  event  causes  another  event  to  be  scheduled  for  some  future  time,  the 
SCS  prevents  a  routine  which  is  processing  the  first  event  from  simply 
calling  a  routine  to  process  the  second  event.  The  flow  of  control  must 
pass  through  the  SCS  routines  which  ensure  that  any  intervening  events  are 
simulated  first. 

1.5  MAJOR  FUNCTIONAL  MODULES 

The  event  processing  subroutines  in  TRACE  are  separated  into  ten 
major  modules:  PLAN,  PERCEPT,  PONDER,  MOVE,  COMBAT,  FIRE,  SHOOT,  COMMO, 
ASSIGN,  and  TIMEOUT.  The  following  paragraphs  give  brief  descriptions  of 
each  of  these  major  modules. 

1.5.1  Maneuver  Planning  Module  -  PLAN 

This  module  contains  the  routines  associated  with  planning  a 
military  operation  based  on  an  operations  order.  This  includes  refining 
orders  to  pass  down  to  subordinates  what  their  part  of  the  operation  is  to 
be.  As  the  situation  develops,  minor  changes  to  the  plan  are  carried  out 
in  the  PONDER  module. 

1.5.2  Sensory  Perception  Module  -  PERCEPT 

This  module  is  concerned  with  simulating  all  the  relevant  capa¬ 
bilities  of  a  unit  to  receive  information  or  react  to  input  stimuli.  This 
input  includes  visual  sightings,  receipt  of  messages,  and  electronic  or 
mechanical  detection  of  phenomena.  Perceptions  simulated  by  this  module 
are  placed  on  a  queue  for  later  response  under  the  PONDER  module. 
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1.5.3 


Information  Fusion  and  Decision-Making  Module  -  PONDER 
This  module  is  concerned  with  acting  upon  all  if  the  input  stim¬ 
uli  received  from  the  PERCEPT  module,  or  special  stimuli  initiated  by 
another  module.  The  unit's  status  is  examined,  and  proper  responses  are 
scheduled. 

1.5.4  Non-combat  Ground  Movement  Module  -  MOVE 

Movement  of  units  that  are  not  in  combat  is  processed  through 
this  module.  The  units  move  in  accordance  with  guidelines  contained  in 
their  operations  orders,  such  as  location  of  objective  or  phaseline,  time 
requirements,  and  lateral  boundaries.  Other  factors,  such  as  the  location 
of  nearby  units  and  terrain  requirements,  are  also  considered. 

1.5.5  Ground  Combat  Module  -  COMBAT 

This  module  contains  the  routines  which  deal  with  those  phenomena 
occurring  in  direct  fire  ground  combat  interactions  between  opposing  units, 
including  combat  movement.  Events  processed  in  this  module  are  continuous 
events;  i.e.,  this  module  is  time-stepped. 

1.5.6  Indirect  Artillery  Fire  Module  -  FIRE 

This  module  handles  all  of  the  processing  requirements  necessary 
to  queue  up  artillery  requests  at  a  fire  direction  center,  subsequently  to 
service  those  requests  by  firing  batteries,  and  to  assess  the  results  of 
the  fire  mission  in  terms  of  casualties  caused  and  ammunition  expended. 

1.5.7  User  Directed  Nuclear  Strikes  -  SHOOT 

This  module  causes  a  nuclear  strike  to  be  executed  at  the  direc¬ 
tion  of  the  TRACE  user.  The  strike  will  occur  in  a  designated  level  3  hex. 
(See  Appendix  A  for  a  discussion  of  hex  levels.) 

1.5.8  Communications  Module  -  COMMO 

This  module  is  concerned  with  simulating  the  transmission  of 
messages  from  one  unit  to  another.  In  addition,  the  module  contains 
the  code  concerned  with  direction  finding,  intercepting,  and  jamming 
procedures. 

1.5.9  Temporary  Game  Timeout  Module  -  TIMEOUT 

This  module  is  used  to  record  snapshots  of  data  structures  for 
future  analysis  or  to  perform  a  check-point/restart  operation  for  possible 
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future  reruns  of  the  model  without  having  to  restart  from  the  very 
begi nni ng. 

1.5.10  Reassignment  of  Units  -  ASSIGN 

This  module  controls  the  reassignment  or  reorganization  of  force 
structures.  It  processed  the  assumption  of  command  by  another  company  when 
a  headquarters  company  is  lost  and  it  accepted  time  oriented,  user  directed 
reorganization  for  task  directed  operations. 

1.6  SIMULATION  JOB  CONTROL  PROCESS 

An  overview  of  the  TRACE  simulation  process  is  shown  in  Figure  1. 
The  process  consists  of  two  distinct  phases,  initialization  and  execution. 
During  initialization,  the  combat  scenario  is  defined  by  inputting  the  unit 
descriptions,  weapon  system  characteristics,  and  communication  and  elec¬ 
tronic  .warfare  descriptions.  These  inputs  are  used  to  build  the  data 
structures  and  various  lists  comprising  the  initial  dynamic  storage  array. 
The  dynamic  storage  array  is  updated  as  the  simulation  progresses,  and  it 
provides  an  up-to-date  status  of  the  simulation  at  any  point  in  time. 

The  execution  phase  is  actually  a  series  of  runs  to  simulate  each 
step  of  the  war.  Each  run  step  begins  with  the  loading  of  the  dynamic 
storage  array  from  the  previous  step  and  also  the  Red  and  Blue  operations 
orders  for  this  run.  The  actual  simulation  consists  of  the  control  rou¬ 
tines  invoking  the  various  modules  to  execute  continuous  and  discrete 
events.  This  execution  produces  a  variety  of  outputs  including  running 
commentary  on  the  major  actions,  status  summaries  of  the  various  units,  and 
any  signal  intelligence  gained  over  this  period  of  simulation.  At  the  end 
of  the  run,  the  dynamic  storage  array  is  saved  for  the  next  step.  The  user 
then  evaluates  the  output  information  and  prepares  operations  orders  for 
the  next  run  step. 

TRACE  is  currently  running  on  a  Cyber  176  computer  under  the 
NOS/BE  1.2  operating  system.  The  simulation  consists  of  approximately 
450  FORTRAN  subroutines  requiring  50,000  60-bit  words  of  small  core  memory 


(SCM)  and  between  30  to  65  thousand  (depending  on  the  scenario)  60-bit 
words  of  large  core  memory  (LCM).  The  computer  run  time  for  a  simulation 
is  extremely  dependent  on  the  combat  scenario.  Test  runs  with  a  limited 
breakthrough  scenario  have  required  30  to  40  CP  seconds  per  hour  of  combat 
simulation  time. 

15 


*  u- 

■  1 


1  "EJBHP? 


i 


INPU 


I 


Figure  1.  TRACE  mode]  overview. 


SECTION  2 

SIMULATION  INPUT  DESCRIPTION 


2.1  INTRODUCTION 

There  are  five  basic  types  of  user  inputs  to  the  TRACE  simula¬ 
tion: 

(1)  Input  sentences  defining  the  combat  scenario,  i.e.,  the 
command  and  control  relationships,  unit  locations,  and  force 
levels. 

(2)  Data  base  values  defining  the  various  weapon  system  charac¬ 
teristics  such  as  firing  rates  and  attrition  probabilities. 

(3)  Communication  and  electronic  warfare  inputs  describing  unit 
and  system  capabilities  in  these  areas. 

(4)  Operations  orders  for  each  simulation  phase. 

(5)  User  directives  controlling  the  execution  of  TRACE. 

The  first  three  of  these  inputs  are  used  only  in  the  initialization  phase 
of  the  simulation  in  order  to  define  the  scenario.  These  values  (except 
for  unit  locations  and  force  levels)  remain  fixed  throughout  the  simula¬ 
tion.  Thus,  if  the  scenario  is  to  be  changed  (e.g.  ,  an  increase  or 
decrease  in  the  number  of  units,  or  an  adjusted  attrition  probability),  the 
initialization  phase  must  be  redone.  The  operations  orders  and  user 
directives  are  input  at  the  start  of  each  execution  phase  of  the  simula¬ 
tion.  The  orders  determine  the  basic  combat  plan  for  each  side.  The 
directives  determine  the  available  outputs,  execution  length,  etc. 

2.2  UNIT  DESCRIPTIONS 

The  User  Oriented  Input  Language  (UOIL)  has  been  developed  for 
the  METRIC  Family  to  provide  the  user  the  capability  to  define  inputs  using 
English-like  sentence  descriptions  of  the  units  comprising  the  combat 
scenario.  These  sentences  describe  the  command  and  control  relationships 
among  the  various  units  as  well  as  their  location  and  equipment  on  hand. 
Figure  2  is  an  example  of  UOIL  input  for  part  of  a  NATO  force.  The 
following  paragraphs  briefly  describe  the  various  types  of  sentences  used 
in  the  UOIL  input. 


NATO. 

US. 

5  CORPS  COMMANDS  5  HHC. 

5  HHC  IS  AT  HEX  777773277 . 

5  HHC  HAS  1  ATU ,  40  ROUNDS. 

5  CORPS  COMMANDS  3  ARMDIV. 

3  ARMDIV  COMMANDS  3  HHC. 

3  HHC  IS  AT  HEX  777772733 

3  HHC  HAS  1  ATU,  40  ROUNDS. 

3  ARMDIV  COMMANDS  2  ARMBDE. 

2  ARMBDE  COMMANDS  20  HHC. 

20  HHC  IS  AT  HEX  777772246. 

20  HHC  HAS  1  ATU,  40  ROUNDS. 

2  ARMBDE  COMMANDS  22  MECHBN. 

22  MECHBN  COMMANDS  220  HHC. 

220  HHC  IS  AT  HEX  777772671 . 

220  HHC  HAS  1  ATU,  40  ROUNDS. 

22  MECHBN  COMMANDS  221  ARMCO. 

221  ARMCO  IS  AT  HEX  777772677. 

221  ARMCO  HAS  17  TANKS,  1  ATU,  1071  ROUNDS. 
22  MECHBN  COMMANDS  222  MECCO. 

222  MECCO  IS  AT  HEX  777772673. 

222  MECCO  HAS  13  ATU,  128  ROUNDS. 

3  ARMDIV  COMMANDS  4  QIVARTY. 

4  DIVARTY  COMMANDS  40  HHB. 

40  HHB  IS  AT  HEX  777772734. 

40  HHB  HAS  1  ATU,  40  ROUNDS. 

4  DIVARTY  COMMANDS  41  ARTY BN. 

41  ARTYBN  COMMANDS  410  HHB. 

410  HHB  IS  AT  HEX  777772736. 

410  HHB  HAS  1  ATU,  40  ROUNDS. 

41  ARTYBN  COMMANDS  411  BTY175. 

411  BTY175  IS  AT  HEX  777772274. 

411  BTY175  HAS  1  ATU,  4  TUBES,  416  ROUNDS. 


Figure  2.  Example  of  user  oriented  input  language  (UOIL). 
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2.2.1 


Side  and  Nationality  Sentences 

At  the  beginning  of  the  input  for  the  forces  for  either  Red  or 
Blue,  a  simple  declaration  of  "WP"  or  "NATO",  respectively ,  will  signify 
that  all  units  which  follow  will  belong  to  that  side,  either  until  the  end 
of  the  data,  or  until  another  side  sentence  is  encountered.  The  nation¬ 
ality  sentence  works  in  the  same  manner.  At  the  present  time,  the  nation¬ 
ality  sentence  will  not  cause  units  of  a  different  nationality  on  the  same 
side  to  act  according  to  different  doctrine.  For  a  list  of  acceptable  side 
and  nationality  codes,  see  Appendix  C. 

2.2.2  Command  and  Control  Sentence 

This  sentence  describes  who  commands  whom  in  the  combat  scenario 
and  has  the  following  form: 

N1  "typeechelon"  COMMANDS  N2  "type-echelon". 

N1  and  N2  are  the  numerical  designations  of  the  respective  units,  while 
"type-echelon"  specifies  the  type  of  unit.  For  example, 

101  MECHDIV  COMMANDS  2  ARMBDE. 

"MECHDIV"  is  an  abbreviation  for  Mechanized  Division  and  "ARMBDE"  stands 
for  Armored  Brigade.  For  a  list  of  acceptable  unit  types  see  the  gram¬ 
matical  definitions  in  Appehdix  C. 

2.2.3  Unit  Location  Sentence 

The  location  sentence  specifies  the  hex  address  where  a  unit  is 
located  at  the  beginning  of  the  combat  simulation.  (For  a  description  of 
hex  addresses  and  the  hexagonal  coordinate  system,  see  Appendix  A.)  This 
sentence  is  of  the  form: 

N1  "type-echelon"  IS  AT  HEX  HI  . 

HI  is  the  hex  address  where  the  unit  is  located.  For  example, 

5  HHC  IS  AT  HEX  777773277  . 

Note  that  only  company  level  units  have  input  locations;  all  other  echelons 
derive  their  aggregated  location  from  the  location  of  their  subordinates. 
Because  the  hex  address  is  an  integer,  at  least  one  space  must  come  between 
it  and  the  period  (.)  following  it. 

2.2.4  Material  Sentence 

This  sentence  describes  the  ammunition  and  equipment  a  unit  has 
on  hand  at  the  beginning  of  a  simulation  and  is  of  the  form: 


N1  "type-echelon"  HAS  Ml  "material  type",  M2  "material  type", 
etc.  Ml  and  M2  are  the  numbers  of  the  specified  material  or  equipment  the 
unit  currently  possesses.  For  example, 

221  ARMCO  HAS  17  TANKS,  1  ATU ,  1971  ROUNDS. 

For  a  list  of  the  permissible  material  types,  see  the  grammatical  defini¬ 
tion  of  UOIL  in  Appendix  C. 

A  type  number  may  also  be  specified  for  each  material  type.  The 

default  of  this  is  type  1.  When  another  type  is  desired  the  sentence  has 

the  form: 

N1  "type-echelon"  HAS  Ml  "material  type"  OF  TYPE  N2 
N2  is  an  integer  number  differentiating  the  type.  For  Example, 

220  HHC  HAS  1  ATU,  40  ROUNDS,  3  RADIOS  OF  TYPE  2  . 

In  this  example  only  the  radios  are  of  type  2.  The  type  phrase  may  be 

added  to  any  "material  type".  At  this  time  only  radios  are  affected.  Note 

the  space  before  the  period  at  the  end  of  the  example.  This  is  because  the 
type  number  is  an  integer. 

2.3  WEAPON  SYSTEM  CHARACTERISTICS 

The  TCOR  data  base  inputs  to  describe  weapon  system  character¬ 
istics  include  five  classes  of  data: 

(1)  Attrition  factors; 

(2)  Maximum  firing  rates; 

(3)  Maximum  firing  ranges; 

(4)  Maximum  movement  rates;  and, 

(5)  Maximum  acquisition  ranges. 

The  attrition  rates,  firing  rates,  and  firing  ranges  are  speci¬ 
fied  for  infantry,  armor,  tube  artillery,  and  rocket  artillery.  Movement 
rates,  and  acquisition  ranges,  in  addition  to  being  defined  for  units  of 
these  four  classes,  are  also  defined  for  headquarters  companies  or  bat¬ 
teries.  A  separate  set  of  input  values  is  read  for  each  side. 

Figure  3  provides  a  short  definition  of  each  of  these  weapon 
characteristics,  along  with  the  variable  names.  Figure  4  displays  the  for¬ 
mat  order  in  which  the  variables  are  read  (Blue  first  then  Red).  Figure  5 
is  an  example  of  an  input  set  which  was  used  in  a  TRACE  test  scenario. 
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The  following  variables  are  attrition  coefficients  for  weapons  (conventional  and  nuclear). 
These  coefficients  are  floating  point  numbers,  between  0.0  and  1.0,  and  are  used  to  tune  the 
kill  rate  equations.  They  have  no  correspondence  to  a  concise  interpretation. 
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1)  TO  card  images  are  read  for  each  side,  Blue  first  then  Red. 

2)  Variables  are  read  from  the  card  images  in  the  order  shown  above  in 
free  format. 

3)  Those  variables  beginning  with  the  letter  "A"  or  "R"  are  read  as  real 
numbers,  while  those  beginning  with  "L"  or  "M"  are  read  as  integers. 


Figure  4.  Weapon  systems  input  format. 
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Figure  5.  Example  TRACE  weapon  system  input. 


In  Figure  5,  the  test  outside  the  dashed  line  does  not  occur  on  the  input. 
It  is  provided  for  ease  of  reading  only. 

2.4  COMMUNICATION/ELECTRONIC  WARFARE  INPUTS 

TRACE  performs  detailed  simulation  of  communication  networks  and 
SIGINT,  direction  finding,  and  jamming  efforts  against  message  traffic  over 
these  networks.  To  perform  this  detailed  communication  simulation,  the 
user  must  input: 

a.  Communication  network  characteristics ; 

b.  Communication  net  members;  and, 

c.  EW  equipment  characteristics. 

2.4.1  Communication  Network  Characteri sties 


speci fy: 


In  order  to  define  a  communication  network,  the  user  must 


Equipment/traff ic  characteristics  of  the  net; 

Unit  members  of  the  network. 

Figures  6  and  7  are  examples  of  communication  net  inputs  for  the  BLUE  3rd 
Division  Command  Net  and  3rd  Brigade  Intelligence  Net.  Also,  Figure  8  is 
the  exact  computer  card  format  needed  to  define  a  communication  net. 

Twenty  equipment/traffic  characteristics  are  needed  in  the  input 
definition  of  a  net: 

1 .  Side 

Indicates  whose  network  is  being  defined.  At  this  time 
only  BLUE  nets  are  modeled. 


Indicates  type  of  message  traffic  normally  transmitted  over 
the  network.  In  TRACE,  there  are  5  possible  network  types: 

1  -  Operations  Command  Net  to  handle  operations  orders 

from  a  commander  to  his  subordinates. 

2  -  Administrative  Net  for  status  reports  from  a 

subordinate  to  his  commander. 

3  -  Artillery  Request  Net  for  support  requests  from  a 

unit  to  artillery  battalions. 


i 


Figure  6.  Example  communications  input  -  command  net. 


NOUVUCMHOD  WOR  HI  I 


Figure  8.  Input  format  for  defining  a  communications  network 
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Intelligence  Net  for  intelligence  reports  from  a 
subordinate  to  his  commander. 

5  -  Close  Air  Support  Net  for  support  requests  from 

units  to  the  corps  air  base. 

3.  Net  Level 

Indicates  echelon  of  net  control  station:  Corps  (7); 
Division  (6);  Brigade  (5);  Battalion  (4). 

4.  Security  Mode 

This  field  is  reserved  for  use  with  a  capability  that  is 
under  development.  For  present  purposes  always  input  a  1 
(one)  signifying  clear  transmissions. 

5.  Transmission  Mode 

Indicates  manner  in  which  messages  are  transmitted  over  this 
network:  voice  transmissions  (1);  teletype  transmissions 

(2);  and  facsimile  transmissions  (3). 

6.  Number  of  Channels 

Indicates  number  of  discrete  channels  available  on  communi¬ 
cation  equipment  for  this  net.  (Not  used  in  TRACE  versions 
of  TCOR. ) 

7.  Number  of  Stations  in  Net 

Indicates  total  number  of  units  which  are  members  of  this 
net.  This  number  should  exactly  match  the  number  of  units 
listed  after  the  net  characteristics. 

8.  Net  Frequency 

Indicates  frequency  (in  megahertz)  at  which  messages  are 
transmitted  over  this  net. 

9.  Max  Frequency 

Indicates  highest  frequency  at  which  net  communication 
equipment  can  transmit. 

10.  Min  Frequency 

Indicates  lowest  frequency  at  which  net  communication  equip¬ 
ment  can  transmit. 
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11.  Outy  Cycle 


Included  for  future  development.  User  should  input  0.0  or 
any  other  legitimate  percentage. 

12.  Background  Traffic 

Indicates  percentage  of  time  which  net  is  transmitting  back¬ 
ground  traffic.  Net  will  be  considered  busy  this  percentage 
of  time. 

13.  Chance  of  a  Security  Break  on  this  Net 

This  field  is  reserved  for  use  with  a  future  capability.  At 
present  always  input  0.0. 

14.  Max  Effective  Communication  Distance  Expected 

Indicates  maximum  distance  (in  kilometers)  at  which  the  net 
communication  equipment  can  be  effective. 

15.  Courier  Speed 

Indicates  speed  (in  kilometers/hour)  at  which  couriers  for 
the  units  in  this  net  can  deliver  messages  that  cannot  get 
through  by  electrical  means. 

16.  Average  Message  Length 

Indicates  average  time  (in  minutes)  of  transmission  for  type 
of  traffic  normally  transmitted  over  this  net. 

17.  Connect  Time  Delay 

Included  for  future  development.  User  should  input  "0.0". 

18.  Time  at  Which  to  Use  Courier 

Indicates  average  amount  of  time  (in  minutes)  a  unit  will 
spend  trying  to  get  a  message  through  on  this  net  before 
sending  the  message  by  courier. 

19.  Time  Before  Using  Alternate  Route 

Indicates  average  amount  of  time  (in  minutes)  a  unit  will 
spend  trying  to  send  a  message  over  this  net  before  trying 
an  alternate  net. 

20.  Time  Before  Using  Alternate  Route  When  this  Net  Jammed 
Indicates  average  amount  of  time  (in  minutes)  a  unit 
requires  to  determine  that  this  net  is  jammed  beyond 
effective  use. 
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2.4.2 


Communication  Net  Members 

In  order  to  define  a  communication  net,  the  user  must  also 
specify  all  members  of  the  net.  This  is  done  by  listing  all  units  in  the 
net  immediately  after  the  net  character! sti cs.  In  order  to  avoid  ambigu¬ 
ity,  units  are  identified  using  a  required  input  format: 

XXX  CORPS  XXX  DIV  XXX  8DE  XX  BN  XXX  CO  XXXXX.X  %  DUTVCYCLE 
The  unit's  designation  number  together  with  the  designation  number  for  each 
commander  in  his  chain  of  command  must  be  listed.  (The  duty  cycle  entry 
will  be  explained  later.)  Note  that  a  number  must  be  input  at  each  command 
level,  corps  through  company.  If  there  is  no  commander  in  the  unit's  chain 
at  a  certain  level,  then  a  0  should  be  input.  Consider  the  following 
examples: 

30th  Headquarters  Company  of  the  3rd  Division 
5  CORPS  3  DIV  0  BDE  0  BN  30  CO 

The  unit  number  of  this  company  is  30;  it  reports  directly  to  the  3rd  Divi¬ 
sion,  so  there  are  no  battalions  or  brigades  in  his  chain  of  command;  the 
only  corps  in  this  scenario  is  the  5  Corps. 

3rd  Division 

5  CORPS  3  DIV  0  BDE  Q  BN  Q  CO 

This  is  a  division  level  unit;  hence,  there  are  no  companies,  battalions, 
or  brigades  in  the  chain  of  command. 

2nd  Brigade  of  the  3rd  Division 
5  CORPS  3  DIV  2  BDE  0  BN  0  CO 

Note  that  there  is  an  inherent  scenario  limitation  in  this  numbering 
system:  subordinates  (at  the  same  echelon  level)  of  the  same  commander  must 
have  unique  unit  designation  numbers;  e.g.  ,  there  cannot  be  a  3rd  Armored 
Division  and  a  3rd  Infantry  Division  both  commanded  by  the  5th  Corps. 

For  this  simulation,  companies  do  not  send  actual  messages. 
Hence,  net  members  must  be  battalion  level  or  higher.  However,  the  actual 
physical  location  of  a  unit's  communication  equipment  is  at  the  unit's 
headquarters  company.  When  specifying  members  of  a  network,  with  this  input 
format,  the  unit  which  is  net  control  station  should  be  the  first  unit  in 
the  list,  and  there  should  be  an  input  line  for  each  net  member.  In 


addition  to  the  designation  numbers  for  a  unit,  there  must  also  be  an  input 
entry  for  the  unit's  net  duty  cycle.  This  number  represents  the  percentage 
of  total  net  transmission  which  this  unit  is  transmitting.  This  number  is 
included  for  future  development,  and  is  not  used  at  present;  hence,  any 
legitimate  percentage  is  permissible.  Figure  6  is  an  example  of  the  input 
format  used  to  specify  a  communication  net.  This  net  is  composed  of  the 
3rd  Division  (net  control  station)  and  the  1st,  2nd,  3rd,  and  4th  Brigades. 
2.4.3  EW  Equipment 

TRACE  simulates  3  types  of  EW  equipment: 

Jamming  Equipment; 

Intercept/Listening  Equipment; 

Radio  Direction  Finding  Equipment. 

In  order  to  input  an  item  of  EW  equipment,  the  user  must  specify  the 
characteristics  of  each  separate  piece  of  equipment  along  with  a  list  of 
those  Red  units  having  this  type  of  equipment.  The  same  input  format  is 
used  for  all  types  of  equipment.  See  Figure  12  for  an  example  of  the 
required  input  format.  Figures  9,  10,  and  11  illustrate  Red  EW  data  input. 
Twelve  equipment  characteristics  are  needed  for  input  definition: 

1 .  Side 

Indicates  whose  equipment  is  being  defined.  At  this  time 
only  Red  equipment  is  modeled. 

2.  Type  Equipment 

Specifies  equipment  type  described  by  these  input  character¬ 
istics.  Input  codes  used  are: 

1  -  Jamming  Equipment;  2  -  Intercept  Equipment;  3  -  DF 

Equipment. 

3.  Number  of  Scanners 

Applies  only  to  intercept  equipment  (0  should  be  used  for  DF 
and  Jamming  Equipment).  Represents  number  of  discrete  fre¬ 
quencies  an  intercept  unit  can  listen  to  simultaneously. 
(NOTE:  This  parameter  allows  user  to  group  intercept  equip¬ 
ment  of  the  same  type. ) 
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Figure  12.  Input  format  to  specify  EW  equipment 


4.  Number  of  Primary  Nets  Targeted 

Inc’uded  for  future  development;  user  should  input  .. 

5.  EW  Policy  for  this  Equipment 

Included  for  future  development;  user  should  input  0. 

6.  Number  of  Units  with  This  Type  of  Equipment 

Indicates  total  number  of  this  type  equipment  possessed  cy 
Red  EW  units.  This  number  should  exactly  match  the  number 
of  units  listed  after  the  equipment  characteristics.  (NOTE: 
If  a  unit  possesses  more  than  one  piece  of  this  equipment, 
it  should  be  included  in  the  input  list  a  correspond]' ng 
number  of  times.)  Each  piece  of  equipment  ’s  assumed  to  ce 
collocated  with  the  unit  to  which  it  belongs. 

7.  Maximum  Effective  Distance 

Indicates  maximum  distance  (in  kilometers)  at  which  equip¬ 
ment  is  effective. 

8.  Maximum  Frequency 

Indicates  the  highest  frequency  (in  megahertz)  at  which  this 
equipment  can  operate  effectively. 

9.  Minimum  Frequency 

Indicates  the  lowest  frequency  (in  megahertz)  at  which  this 
equipment  can  operate  effectively. 

10.  Jamming  Bandwidth 

Indicates  the  bandwidth  (in  megahertz)  that  a  jammer  covers. 
It  is  zero  for  OF  and  intercept  equipment. 

1 1 .  Minimum  Time  to  Scan/DF 

Used  for  intercept  and  OF  equipment  only.  For  intercept 
equipment,  it  is  the  average  time  (in  seconds)  required  to 
determine  that  a  signal  on  a  specific  channel  is  of  interest 
(assuming  that  it  has  already  been  determined  that  a  signal 
is  being  transmitted  on  this  channel).  For  OF  equipment,  it 
indicates  the  average  time  (in  seconds)  required  to  obtain  a 
bearing  on  a  signal  once  the  signal  frequency  has  been 
determined. 
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1 2 .  Scan  Time  Per  Channel 

Used  for  intercept  and  DF  equipment  or’v.  ’''me  ;  ;  - 

seconds)  required  for  this  equipment  to  move  r>cm  one 
cnannel  to  t^e  next. 

Immediately  after  the  equipment  character'  sties  tnere  should  oe  a 
i'st  of  tne  unit  locations  of  this  piece  of  eauioment.  The  same  ;nput  code 
^ormat  as  explained  earlier  for  communication  net  members  snou’d  be  usee, 
however,  for  EW  equipment,  the  units  snou-d  all  be  company  size.  Ttv s 
equipment  wil1  pe  located  at  the  same  physical  location  as  the  un’t.  Tre 
echelon  names  of  the  input  format  have  been  changed  to  tank  army,  division, 
regiment,  battalion,  and  company  in  order  to  be  consistent  with  RED  Army 
terminology  as  used  in  the  examples: 
a  XX  TA  XXX  0 1 V  XXX  REG  XXX  BN  XXX  CO 

For  example,  suppose  there  is  only  one  HF  listener  which  is  collocated  with 
tne  32Qth  Company  of  the  82nd  Battalion.  Then,  its  unit  input  line  after 
the  equipment  characteri sties  would  be: 

1  TA  9  OIV  8  REG  82  BN  820  CO 
At  this  time,  only  RED  companies  810-815  and  820-825  may  have  EW  equipment. 
2.5  OPERATIONS  ORDER  INPUTS 

A  TRACE  simulation  is  actually  a  series  of  simulations  inter¬ 
spersed  with  operations  orders  input  by  the  man- i n-the- 1 oop  (MITL).  At  the 
beginning  of  each  simulation  run,  the  user  specifies  the  amount  of  combat 
time  he  wants  to  simulate  and  also  the  operations  orders  for  the  higher 

level  command  units  of  both  Red  and  Blue.  These  higher  level  units  inter¬ 
pret  the  orders,  plan  accdrdingly.  and  issue  appropriate  orders  to  their 
subordinates.  Thus,  the  user  supplies  orders  only  at  the  highest  command 
level,  and  the  orders  for  lower  level  units  are  generated  automatically. 

The  operations  orders  input  for  TRACE  was  designed  for  inter¬ 
active  use  by  the  MITL.  However,  this  input  is  currently  done  in  batch 
mode  for  the  AFWL  computer.  The  user  supplies  an  input  deck  of  cards,  each 

of  which  is  the  appropriate  answer  to  an  interactive  prompt.  The  user 

should  use  caution  when  submitting  orders  in  this  bstch  mode.  Since  the 
program  attempts  to  validate  most  of  the  responses,  it  is  extremely 


important  to  carefully  check  all  cards  in  the  input  deck.  If  there  is  an 
invalid  input  card,  the  processor  assumes  the  next  card  is  the  corrected 
response.  Therefore,  be  sure  all  answers  to  the  questions  are  correct  and 
conform  to  the  input  described  below. 

The  following  is  a  description  of  the  interactive  method  for 
inputting  operations  orders.  To  input  in  the  batch  mode,  the  user  should 
supply  the  answers  in  the  proper  sequence.  (For  an  example  of  this  batch 
mode  input,  see  Figure  13.) 


OPORD  and  Jamming  Orders  Inputs 


The  following  is  an  example  of  a  MITL  interactive  session  with 
the  appropriate  prompts,  instructions,  and  replies  that  would  normally  be 
provided.  Processor  questions  and  instructions  given  below  are  underlined 
and  numbered.  Additional  information  regarding  some  of  the  questions  has 
been  provided  (enclosed  in  double  quotation  marks)  when  necessary  for  those 
items  that  are  not  fully  self-explanatory.  After  each  instruction/ 
question,  respond  by  entering  the  information  requested  after  the  "?"  and 
hitting  the  carriage  return. 

All  times  are  expressed  as  DAY-HOUR-HOUR-MINUTE-MINUTE.  The  run 
represents  the  first  execution  run  from  time  10000  to  10800  (480  minutes) 
with  the  actual  action  of  the  simulation  to  start  at  dawn  of  the  first  day. 
The  Blue  Fourth  Artillery  Brigade  is  being  transfered  from  the  Fourth 
Division  to  the  Third  Division.  The  Third  Division  for  Blue  is  given 
orders  to  engage  in  a  defend  operation  from  10600  to  10830.  The  extra 
thirty  minutes  that  the  operations  order  is  to  be  in  effect  allows  for  the 
time  lapse  of  the  next  set  of  orders  on  the  following  run  (from  10800  to 
11000)  as  they  are  being  sent  to  the  lower  echelons.  No  nuclear  weapons 
are  permitted.  The  Third  Division  is  given  one  phaseline  and  told  to 
defend  using  a  screen/move  operation.  Red  has  been  told  to  turn  on  jammers 
for  Unit  814  for  one  hour  at  56.250  megahertz  beginning  at  10700. 

The  following  represents  what  the  user  will  see  as  he  corresponds 
with  the  processor  via  an  input/output  terminal: 


(1)  ENTER  TIME  POINT  TO  HOOK  ORDERS  TO  (ENTER  TIME  IN  SECONDS) 

"Because  the  OPORD  processing  will,  at  times,  need  to  know  where 
a  unit's  data  is  stored  in  memory;  it  must  operate  on  the  parti¬ 
cular  checkpoint  that  will  be  used  for  execution." 

?  0 

(2)  ENTER  LEVEL  FOR  INSTRUCTION  (FULL/PARTIAL) 

?  FULL 

(3)  ENTER  LENGTH  OF  NEXT  RUN  (MINUTES) 

?  480 

(4)  WHICH  SIDE  (RED/BLUE/NONE)  FOR  NUCLEAR  STRIKE 
?  RED 

(5)  ENTER  GAME  TIME  OF  BURST  (TDGZ)  IN  SECONDS 

?  7200 

(6)  ENTER  TEN  TIMES  THE  YIELD  IN  KILOTONS  (INTEGER) 

?  200 

(7)  ENTER  TARGET  HEX 

?  777772635 

(8)  REVIEWING  WHAT  YOU  HAVE  ENTERED 

20.0KT  BURST  SET  OFF  IN  HEX  777772635  AT  7200  SECONDS  INTO  THE  GAME 
IS  IT  ACCEPTABLE  (YES/NO) 

?  YES 

(9)  WHICH  SIDE  (RED/BLUE/NONE)  FOR  NUCLEAR  STRIKE 
?  NONE 

(10)  WHICH  SIDE  (REP/BLUE/NONE)  "For  reassignment/reorganization  orders." 

?  BLUE 

(11)  ENTER  UNIT  TO  BE  MOVED 
INPUT  UNIT  DESIGNATION: 

CORPS/CAA ,  QIV.  BDE/REG,  BN 

WITH  ZERO  (0)  WHERE  NO  UNIT  AT  THAT  ECHELON 
"5  Corps  4  Division  4  Brigade." 

?  5,  4,  4,  0 
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(12)  ENTER  OLD  COMMANDER 
INPUT  UNIT  DESIGNATION: 

CORPS/CAA ,  DIU .  BDE/REG,  8N 

WITH  ZERO  (Q)  WHERE  NO  UNIT  AT  THAT  ECHELON 
?  5,  4,  0,  0 

(13)  ENTER  NEW  COMMANDER 
INPUT  UNIT  DESIGNATION: 

CORPS/CAA,  DIV,  BDE/REG,  BN 

WITH  ZERO  (0)  WHERE  NO  UNIT  AT  THAT  ECHELON 
?  5,  3,  0,  0 

(14)  ENTER  EFFECTIVE  TIME  (IN  SECONDS)  OF  GAME  "After  one  hour." 

?  3600 

(15)  REVIEWING  WHAT  YOU  HAVE  ENTERED 

DO  YOU  WANT  TO  USE  THIS  REASSIGNMENT  (YES/NQ) 

?  YES 

(16)  WHICH  SIDE  (RED/BLUE/NONE)  “For  reassignment" 

?  NONE  "To  end  reassignments." 

(17)  WHICH  SIDE  (RED/BLUE/NONE)  "For  Operations  Orders" 

?  BLUE 

(18)  INPUT  UNIT  DESIGNATION 
CORPS/CAA, DIV, BDE/REG, BN 

WITH  ZERO  (Q)  WHERE  NO  UNIT  AT  THAT  ECHELON 
"Ex.  for  5  Corps,  3  Division" 

?  5, 3, 0,0 

(19)  INPUT  OPERATION  (ATK/OEF) 

"Attack  or  defend  -  overall  operation  type  for  this  unit  and  subordinates 
for  the  duration  of  this  OPORD" 

?  DEF 

(20)  INPUT  INITIAL,  FINAL  TIMES  AS  INTEGER  DHHMM 

"Enter  the  initial  and  end  time  for  the  effect  of  this  order.  Always 
let  the  effective  times  extend  30-45  minutes  past  the  end  of  the  next 
run.  This  allows  the  old  order  to  be  used  at  the  start  of  each  run 
while  the  new  one  is  being  processed  and  sent  to  the  lower  echelon 
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units."  "Ex.  If  the  order  is  to  be  in  effect  from  10600  to  the  end 
of  the  run,  then  allow  it  to  be  in  effect  from  10600  to  10830." 

?  10600,  10330 

(21)  INPUT  GS  PRIORITY  AS  INTEGER  PERCENT 

"Enter  percent  of  artillery  to  be  used  for  general  support." 

?  50 

(22)  ARE  NUCLEAR  WEAPONS  PERMITTED 

?  NO  "or  YES  as  the  case  may  be" 

(23)  INPUT  ACCEPTABLE  CASUALTY  LIMIT,  AND  MIN  SUPPLY  LEVEL  AS  INTEGER  PERCENTS 

?  20,30 

(24)  INPUT  MIN,  MAX  SPEED  LIMITS  AS  INTEGER  PERCENT  OF  UNIT  THEORETICAL  BEST 
SPEED  "Ex.  For  move  between  20  and  70  percent  of  theoretical  max" 

?  20,70 

(25)  INPUT  LEFT  BOUNDARY  HEXES  (AS  FACE  DIRECTION  OF  MOVEMENT) 

REAR  TO  FRONT,  FOLLOWED  BY  ZERO  (0)  THEN  RIGHT  BOUNDARY  HEXES  —  REAR 
TO  FRONT. 

TERMINATE  LIST  BY  A  NINE  (9). 

"NOTE:  Each  side  of  the  boundary  must  have  at  least  3  coordinates 

since  the  phaseline  will  have  to  terminate  at  an  interior  boundary 
point  on  each  side. " 

"NOTE:  If  any  member  of  the  list  is  not  a  valid  hex  number,  you  will 

be  asked  to  replace  the  incorrect  hex." 

?  777776217,  777772417,777772524,  777772517,  0 

?  777771734,  777772272,  777772212,  777772371,  9 


DO  YOU  NEED 

INSTRUCTIONS  FOR  INPUT  OF  PHASELINES  (YES/NO) 

YES 

YOU  WILL  BE 

ASKED  TO  INPUT  AN  OPERATION 

TYPE  NUMBER  FOR  EACH  PHASE 

THE  CODES  REFER  TO  THE  FOLLOWING: 

CODE 

ATTACK 

DEFEND 

1 

MOVE  TO  CONTACT 

HOLD  POSITION 

2 

BRKTHRU 

DELAY 

3 

HOLDING  ATK 

SCREEN  MOVE 

4 

EXPLOIT 

COUNTERATTACK 

5 

RESERVE 

RESERVE 
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"NOTE:  At  present,  use  only  1  or  2  for  attack,  3  for  defend. 

"Also,  input  the  time  for  the  end  of  the  effect  of  this  particular 
phaseline.  Several  phaselines  may  be  used  in  one  run,  but  if  only  one 
is  input,  then  the  end  time  should  also  extend  past  the  end  of  the  run 
by  30-45  mi nutes. " 

FOR  THE  PHASELINES,  INPUT  THE  HEXES  FROM  LEFT  TO  RIGHT,  MAKING  SURE  TO 
INCLUDE  A  HEX  FROM  THE  LEFT  AND  RIGHT  BOUNDARIES.  TO  TERMINATE  HEXES, 
TYPE  IN  9. 

(27)  INPUT  OPERATION  CODE  (0  TO  TERMINATE),  AS  INTEGER,  END  TIME  OF  PHASE 
AS  INTEGER  DHHMM 

"Ex.  For  defend  and  until  the  end  of  the  effect  of  this  order:" 

?  3,  10830 

(28)  INPUT  HEX  LIST  AS  INTEGERS 

"If  the  first  hex  coordinate  in  the  list  is  not  on  the  left  boundary, 
or  if  the  last  hex  coordinate  is  not  on  the  right  boundary,  then  you 
will  be  asked  to  replace  the  incorrect  coordinate  with  values  that  are 
on  the  corresponding  boundaries  defined  in  (10)." 

?  77777772417,  77777772272,  9 

(29)  INPUT  OPERATION  CODE  (0  TO  TERMINATE).  AS  INTEGER,  END  TIME  OF  PHASE 
AS  INTEGER  DHHMM 

"Repeat  this  input  plus  the  hex  list  (steps  12  and  13)  for  each  phase 
line.  Enter  0,  0  if  no  more  phase  lines." 

?  0,0 

"At  this  time  the  processor  will  output  the  OPORD  for  the  unit.  At 
the  end,  you  will  be  asked  if  you  want  to  use  it.  If  not,  then  say 
NO.  You  may  then  re-input  the  OPORD  or  go  on  to  another  unit's 
OPORD." 

END  OF  PHASE  INPUT  FOR  THIS  UNIT  "OPORD  result  now  follows." 

(30)  DO  YOU  WANT  TO  USE  THE  LAST  OPORD  (YES/NO) 

?  YES 

(31)  WHICH  SIDE  (RED/BLUE/NONE) 

"Do  for  both  Red  and  Blue  sides.  Enter  none  when  finished  with  OPORDS." 
?  NONE 
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(32)  ENTER  SIDE  FOR  JAMMING  SUPPORT  (RED/BLUE/NONE) 

?  RED 

(33)  ENTER  JAMMING  COMPANY  (0,814,815,824,825  ONLY) 

?  814 

(34)  ENTER  FREQUENCY  (MHZ),  START  TIME  (DHHMM),  DURATION  OF  JAMMING  MISSION 
(MINUTES) 

?  56.250,10700,60 

"The  processor  will  show  the  jamming  order  and  ask  for  a  new  one" 

(35)  ENTER  JAMMING  COMPANY 
(0,814,815,824,825) 

?  0 


"When  all  jamming  orders  are  input,  you  will  be  asked  if  you  want  to 
use  them". 

(36)  DO  YOU  WANT  TO  USE  THESE  JAMMING  ORDERS  (YES/NO) 

?  YES 

(37)  ENTER  SIDE  FOR.  JAMMING  SUPPORT 
(RED/BLUE/NONE) 

?  NONE 


2.6  USER  DIRECTIVES 

During  each  execution  the  user  may  specify  a  certain  desired  set 
of  outputs  to  be  generated  by  the  model.  Some  of  these  outputs  are  files 
to  be  used  or  displayed  later  and  others  are  information  displayed  during 
execution.  The  user  must  also  control  the  behavior  of  the  execution. 
Figure  13  shows  a  sample  set  of  user  directives.  Associated  with  each  time 
in  the  figure  is  a  number.  These  numbers  are  used  in  the  following  to 
explain  the  use  of  each  entry: 

Line  1  Column  1-20  This  is  the  seed  for  the  random  number 

generator.  It  is  an  integer  in  base  8.  If  0 
is  used,  the  seed  stored  on  the  checkpoint 
file  wi 1 1  be  used. 

Line  2  Column  1-6  These  are  logical  flags. 

Column  1  Not  used,  enter  F. 

Column  2  Use  T  if  there  are  any  OPORDs  from  the  MITL. 

Use  F  if  none. 
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Column  3-5 
Column  6 

Column  7-16 


Column  17-56 


Line  3  Column  1-10 
Column  1 


Column  2 

Column  3 


Column  4 

Column  5-10 
Column  11-20 

Column  2130 

Column  31-40 

Column  41-50 

Line  4  Column  1-20 


Not  used,  enter  F. 

Use  T  if  a  file  is  to  be  generated  for  the 
post  processor.  Use  F  if  none  is  desired. 

This  is  an  integer  called,  in  the  model, 
INCR.  It  is  the  time  increment,  in  seconds, 
between  data  points  on  the  post  processor 
file  if  one  is  being  generated. 

This  is  40  characters  of  text  giving  a  title 
to  this  instance  of  the  execution. 

These  are  logical  flags. 

This  is  T  if  there  is  to  be  a  maximum  message 
transmission  time  for  Blue  messages.  It  is  F 
otherwi se. 

This  is  the  same  as  column  1  only  for  Red 

messages. 

This  is  T  if  the  Blue  message  transmission 
time  is  to  be  constant.  It  is  F  otherwise. 

If  both  column  1  and  3  are  T  then  column  3 

takes  procedence. 

This  is  the  same  as  column  3  but  for  Red 

messages. 

Not  used,  enter  F. 

Given  that  column  1  is  T  this  is  the  integer, 
maximum  transmission  time  for  Blue. 

Given  that  column  2  is  T,  this  is  the  maximum 
transmission  time  for  Red. 

Given  that  column  3  is  T,  this  is  the  trans¬ 
mission  time  for  Blue. 

Given  that  column  4  is  T,  this  is  the  trans¬ 
mission  time  for  Red. 

This  is  the  integer  time,  in  seconds,  of  the 
checkpoint  used  to  initialize  the  execution. 
This  time  point  must  appear  on  the  ISPACE 
file  or  the  program  stops. 
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Line  5 


Column  1-20 


Line  6 


Column  1-5 


Column  6-15 


Column  16-20 


Column  25 


This  is  the  integer  time,  in  seconds,  that 
the  simulations  runs  (game  time,  not  real 
time). 

Line  6  is  actually  an  example  of  one  of  a 
,  series  of  entries.  Lines  1-5  must  occur  and 
in  that  order.  There  may  be  zero  or  more 
line  6  entries  following  those  5. 

This  is  an  integer  specifying  the  chosen  out¬ 
put  type. 

1  =  a  status  report  display  of  unit  status 
for  both  sides. 

3  =  a  checkpoint  is  written  to  the  ISPACE 
file. 

4  =  code  3  plus  the  model  stops 

This  is  the  wait  time,  in  seconds,  until  the 
first  of  the  output  type  is  generated.  It  is 
an  integer. 

This  is  the  duration,  in  seconds,  between 
successive  outputs  of  this  types.  It  is  an 
i nteger. 

This  is  an  integer  and  is  the  level  of  the 
lowest  unit  to  be  displayed.  It  is  only 
applicable  to  output  type  1.  (See  Appendix  A 
for  discussion  of  levels). 
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SECTION  3 

RUNNING  THE  SIMULATION  (JOB  CONTROL  LANGUAGE) 

3.1  INTRODUCTION 

This  chapter  provides  a  detailed,  step-by-step  explanation  of  the 
Job  Control  Language  (JCL)  necessary  to  run  the  TRACE  simulation  on  the  CDC 
Cyber  176  computer  at  the  Air  Force  Weapons  Laboratory  (AFWL).  The  two 

AFWL  Cyber  176  computers  use  the  NOS/BE  1.2  operating  system.  The  JCL 

explained  in  this  chapter  applies  specifically  to  this  operating  system. 

A  TRACE  combat  simulation  consists  of  four  phases,  initializa¬ 
tion,  MITL,  execution,  and  post  processing.  Section  3.2  describes  the  JCL 

necessary  for  initializing  the  combat  scenario,  section  3.3  describes  the 

MITL  JCL  and  section  3.4  describes  the  actual  simulation  execution  process. 
Section  3.5  describes  the  post  processor. 

3.2  SCENARIO  INITIALIZATION 

The  first  step  of  a  TRACE  simulation  is  to  build  the  initial 
ISPACE  for  the  desired  scenario.  The  term  "ISPACE"  refers  to  the  dynamic 
storage  array  used  to  hold  the  data  structures  and  list  structures  needed 
for  the  simulation.  This  initial  phase  reads  in  the  various  user  inputs 
describing  the  combat  scenario  and  builds  the  necessary  data  structures  and 
lists.  (See  Section  2  for  a  description  of  these  inputs). 

Figure  14  lists  the  JCL  to  run  this  initialization  process  while 
Figure  15  depicts  this  process.  The  remainder  of  this  section  provides  a 
detailed  explanation  of  each  of  these  JCL  steps. 

JCL  EXPLANATION  (INITIALIZE  SCENARIO) 


JOB  CARD. 

ACCOUNT  CARO. 

The  job  and  account  card  formats  for  the  AFWL  computer  system  are 
described  in  AFWL's  system  bulletins  (SYSBULLs).  It  is  important  to  note 
that  the  TRACE  simulation  uses  approximately  30  to  65  thousand  words  of 
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JOB  CARD 
ACCOUNT  CARD 

COMMENT  * ***"* ★★  ★★★★★★★  *★★★*★*★★★  ★★★★★★★★★★★★★★★★★★★★★  ■K'k'k'*  feir'k  ★  ■*•★★'*'*"*••*"*★*'  •*  * 
COMMENT.  TRACE  INITIALIZATION  RUN 

COMMENT  ******  ★★★★★★★★★★★★  *★*■*★■*'★  ★  *★★★★★★★★★★★★★★★★ 

comment!— . - . — . - . - . - . - . . 

COMMENT.  STEP  1  -  GET  FILES  NECESSARY  FOR  TRACE  INITIALIZATION 

COMMENT.  TAPE5  -  UNIT  DESCRIPTIONS 

COMMENT.  TAPE7  -  WEAPON  SYSTEM  CHARACTERISTICS 

COMMENT.  TAPE! 1  -  COMMUNICATION  NETWORKS 

COMMENT.  TAPE! 2  -  ELECTRONIC  WARFARE 

COMMENT.  TAPE2  -  NEW  ISPACE  FILE 

COMMENT.  TLIB  -  TCOR  SUBPROGRAM  LI3RARY 

COMMENT.  '  I N IT  -  INITIALIZATION  PROGRAM  BINARY 

COMMENT. . . . . . . . . 


STEP  1  -  GET  FILES  NECESSARY  FOR  TRACE  INITIALIZATION 
TAPE5  -  UNIT  DESCRIPTIONS 
TAPE7  -  WEAPON  SYSTEM  CHARACTERISTICS 
TAPE! 1  -  COMMUNICATION  NETWORKS 
TAPE! 2  -  ELECTRONIC  WARFARE 
TAPE2  -  NEW  ISPACE  FILE 
TLIB  -  TCOR  SUBPROGRAM  LIBRARY 
I N IT  -  INITIALIZATION  PROGRAM  BINARY 


TAPES'!  .COMBAT, ID=WDNA14CC. 
TAPE92 ,BLUEOB, ID=WDNA1 4CC. 
TAPE93, REDOB, ID=WDNA14CC. 
TAPE94 .REDEWOB , ID=WDNA1 4CC . 
TAPE91 ,TAPE5 . 

TAPE92 ,TAPE5. 

TAPE93  ,TAPE5. 

TAPE94 ,TAPE5 . 

TAPE5 . 

TAPE1 1 ,COMDATA, ID-WDNA1 4CC . 
TAPE! 2 , EWDATA , I D=WDNA1 4CC . 
,TAPE2,*PF. 

INIT,TRACEINIT,ID=WDNA14CC. 
TLIB .TRACELIB , IO=WDNAl 4CC . 


ATTACH, TAPES  1 ,COM 
ATTACH, TAPE92.BLU 
ATTACH,TAPE93 ,RED 
ATTACH, TAPE94, RED 
COPYBR ,TAPE91 ,TAP 
C0PYBR,TAPE92,TAP 
COPYBR, TAPE93, TAP 
COPYBR, TAPE94, TAP 
REWIND, TAPE5. 
ATTACH, TAPE]  1  , COM 
ATTACH, TAPE1 2,  EWD, 
REQUEST, TAPE2,*PF 
ATTACH, INIT, TRACE 
ATTACH, TLIB, TRACE 

COMMENT. . 

COMMENT.  STEP 

COMMENT. . 

LIBRARY, TLIB. 
LDSET ,PRESET=ZERQ 
INIT,PL=20000. 
COMMENT. . 


GET  COMBAT  FACTORS 
GET  BLUE  UNIT  DESCRIPTIONS 
GET  RED  UNIT  DESCRIPTIONS 
GET  RED  EW  UNIT  DESCRIPTIONS 
ADD  TO  A  COMBINED  FILE 
ADD  TO  A  COMBINED  FILE 
ADD  TO  A  COMBINED  FILE 
ADD  TO  A  COMBINED  FILE 
REWIND  THE  COMBINED  FILE 
GET  COMMUNICATIONS  DATA 
GET  ELECTRONIC  WARFARE  DATA 
RESERVE  FILE  FOR  NEW  ISPACE 
GET  TRACE  INITIALIZATION  BINARYS 
GET  TRACE  PROGRAM  LIBRARY 


STEP  2  -  BUILD  INITIAL  ISPACE 


COMMENT.  STEP  3  -  SAVE  INITIAL  ISPACE 

COMMENT. . - . - . . . . . — 

CATALOG ,TAPE2 ,NEWI SPACE ,  ID=WDNA1 4CC ,RP=999 .  SINGLE  ENTRY  ISPACE 
COMMENT.  +++++++++  NAME  OF  ISPACE 

COMMENT  ***************** ** ★★★★★★★★★★★★★★★★  ★★★★★★★★★★★★  ★★★★★★★★★★★★★★★  ★★★★★★★★ 
COMMENT.  INPUT 

rDMMFNT  *★★★★★★*★★★★*★★★★★★★*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 
7/8/9  *  END  OF  RECORD  (JCL) 

INITIALIZE  CODE  WORD  FOR  THE  INITIALIZATION 

17171274121477413155  RANDOM  NUMBER  SEED 

6/7/8/9  END  OF  FILE  (USER  DIRECTIVES) 


Figure  14.  JCL  deck  for  TRACE  initialization. 


TRACE  MODEL  INITIALIZATION 


TEMPORARY 

USER  INPUT  PROCESSING  FILES 


PERMANENT 

files 


5978/7 8>N 


Figure  15.  Model  initialization  process 


Cyber  176  large  core  memory  (LCM),  depending  on  the  scenario.  Hence,  the 
job  card  should  contain  the  appropriate  EC  or  EL  parameters  to  ’"form  the 
system  that  LCM  will  be  needed. 

COMMENT.  STEP  1  -  GET  FILES  NECESSARY  FOR  TRACE  INITIALIZATION 

The  first  step  in  the  initialization  process  is  to  attach  or 
reserve  (as  local  files)  all  of  the  necessary  data  and  program  files.  Four 
parts  of  one  file  are  stored  separately  and  must  be  first  combined. 

ATTACH, TAPE91  .COMBAT ,'ID=WDNA14CC.  COMBAT  FACTORS 

ATTACH, TAPE92.BLUE08, I D=WDNA14CC.  BLUE  UNIT  DESCRIPTIONS 

ATTACH, TAPE93, REDOB, ID=WDNA14CC.  RED  UNIT  DESCRIPTIONS 

ATTACH, TAPE94,RED£W0B,ID=WDNA14CC.  RED  EW  UNIT  DESCRIPTIONS 

C0PYBR.TAPE91 ,TAPE5.  ADD  TO  COMBINED  FILE 

CQPYBR ,TAPE92 ,TAPE5.  ADD  TO  COMBINED  FILE 

COPYBR , TAPE93 ,TAPE5.  ADD  TO  COMBINED  FILE 

COPYBR , TAPE94 , TAPE5.  ADD  TO  COMBINED  FILE 

REWIND, TAPE5.  REWIND  THE  COMBINED  FILE 

ATTACH.TAPEl 1 .COMDATA, ID=W0NA14CC.  COMMUNICATIONS  DATA 

ATTACH , TAPE1 2 , EWDATA , ID=WDNA14CC .  DATA 

These  instructions  attach  the  files  containing  the  inputs  which 
describe  the  combat  scenario.  The  formats  of  these  files  are  described  in 
Section  2.  Note  that  files  91,  92,  93  and  94  are  combined  into  TAP1’ L  by 
the  copy  binary  record  directives  (COPYBR). 

REQUEST, TAPE2,*PF. 

Reserves  permanent  fi^e  space  for  the  new  ISPACE  that  will  be 
created  and  cataloged  by  this  initialization  run.  The  program  will  write 
the  new  ISPACE  to  this  file  at  the  end  of  the  run. 

ATTACH, INIT.TRACEINIT, ID=WDNA14CC. 

Attaches  the  compiled  version  of  the  main  initialization  program. 
This  program  controls  the  initialization  process.  It  is  kept  in  a  separate 
file  from  the  user  library  since  the  library  is  designed  for  subprograms 
and  not  main  programs. 
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ATTACH, TUB ,  TRACElIB  ,  ID=WDNA14CC. 

Attaches,  as  a  local  file,  the  user  library  TRACELIB,  which  con¬ 
tains  the  compiled  versions  of  the  approximately  450  TRACE  subprograms. 
The  system  loader  will  locate  the  routines  needed  for  the  simulation  from 
the  user  1 ibrary. 

COMMENT.  STEP  2  -  BUILD  INITIAL  ISPACE 

LIBRARY, TLIB. 

The  computer  operating  system  is  informed  that  the  file  TLIB  is  a 
user  subprogram  library.  This  library  provides  all  TRACE  subprograms  other 
than  the  main  programs  and  some  FORTRAN  system  routines. 

LDSET , PREScT=ZERO . 

The  loader  is  instructed  to  preset  all  non-initial ized  memory 
locations  to  zero  when  the  TRACE  program  is  loaded  for  execution. 

INIT, PL=20000. 

The  loader  is  instructed  to  load  and  execute  the  TRACE  initial¬ 
ization.  The  main  program  is  loaded  from  the  file  INIT,  while  all  other 
routines  are  taken  from  the  TLIB  user  library  or  the  FORTRAN  system 
library.  The  PL=20000  parameter  instructs  the  system  to  set  the  print  line 
limit  to  20,000  lines  of  output. 

COMMENT.  STEP  3  -  SAVE  INITIAL  ISPACE 

The  purpose  of  the  initialization  is  to  build  the  initial  ISPACE. 
After  this  step  is  completed,  this  initial  ISPACE  is  saved. 

CATALOG , TAPE2 ,NEWISPACE , ID=W0NA14CC , RP=999. 

COMMENT.  +++++++++ 

Saves  the  file  containing  the  ISPACE  created  by  this  initializa¬ 
tion.  The  "•*■+++"  marks  the  name  the  file  will  be  saved  under.  This 
catalog  name  is  normally  ISPACE10000,  to  correspond  to  the  standard  form 
ISPACEDHHMM,  where  0HHMM  indicates  the  combat  simulation  time  which  this 
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ISPACE  represents.  Thus,  10000  indicates  it  is  12  A.M.  on  the  first  day  of 
combat.  The  RP=999  parameter  indicates  the  file  is  to  be  saved  indefi¬ 
nitely.  If  this  parameter  is  left  out,  the  file  is  saved  for  the  length  of 
time  specified  by  the  system  default  (currently  10  days)  and  then  dis¬ 
carded.  (Depending  on  the  size  of  the  file  it  may  be  purged  at  any  time 
regardless  of  the  RP  parameter.) 

COMMENT.  INPUT 

INITIALIZE 

17171274121477413155 

Two  user  directives  are  required.  The  first  is  the  word 
INITIALIZE.  The  second  is  the  seed  for  the  random  number  generator.  This 
permits,  the  user  to  have  with  no  recordkeeping  necessary,  the  all  execu¬ 
tions  derived  from  this  initialization  start  from  the  same  environment. 
This  seed  is  an  octal  (base  8)  integer,  20  digits  long.  (The  random  number 
seed  may  be  overridden  at  execution  if  desired  by  the  user.) 

3.3  MITL  PROCESSING 

Before  the  simulation  can  be  run  or  the  course  of  the  battle 
changed,  the  user  (man-in-the-loop)  must  issue  orders  to  the  units  in  the 
simulation.  (See  Chapter  2  for  an  explanation  of  the  format  of  these 
orders.)  Figure  16  lists  the  JCL  required  to  process  these  orders.  Figure 
17  depicts  this  processing.  The  remainder  of  this  section  details  the  JCL. 

JCL  EXPLANATION  (MITL  PROCESSING) 


JOB  CARD. 

ACCOUNT  CARD. 

The  job  and  account  card  formats  for  the  AFWL  computer  system  are 
described  in  AFWL's  system  bulletins  (SYSBULLs).  It  is  important  to  note 
that  the  TRACE  simulation  uses  approximately  30  to  65  thousand  words  of 
Cyber  176  large  core  memory  (LCM),  depending  on  the  scenario.  Hence,  the 
job  card  should  contain  the  appropriate  EC  or  EL  parameters  to  inform  the 
system  that  LCM  will  be  needed. 
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JOB  CARD 
ACCOUNT  CARD 

COMMENT  ***********************************************■******************'** 
comment!  TRACE  MAN-1N-THE-LOOP  (MITL) 

COMMENT .  **  *★★*★★★*★★★★★★★★★★★★★★★★★★  ★★★★★★  ★★★★★★  ★★★★★★■»»  *■*★★★★★  ★★★★★★  ★★★★★★★ 

COMMENT. . - . . 

COMMENT.  STEP  1  -  GET  THE  NECESSARY  FILES 

COMMENT. . - . - . - . - . - . 

ATTACH, TUB, TRACELIB, ID=WDNA14CC.  GET  TRACE  SUBPROGRAM  LIBRARY 

ATTACH ,TAPE3 , ISPACES , ID=WDNA1 4CC .  GET  OLD  ISPACES 
COMMENT.  +++++++  NAME  OF  ISPACES  FROM  PREVIOUS  RUN 

REQUEST, TAPE47,*PF  RESERVE  FILE  FOR  ORDERS 

ATTACH, MITL, TRACEMITL , ID=WDNA1 4CC.  GET  MITL  BINARY 

COMMENT.— . - . - . - . — 

COMMENT.  STEP  2  -  PROCESS  MITL  DIRECTIVES 

COMMENT. . . - - - - 

LIBRARY, TLIB. 

LDSET , PRESET=Z£RO . 

MITL. 

COMMENT. . - . - . - . 

COMMENT.  STEP  3  -  SAVE  GENERATED  ORDERS 

COMMENT. . - . - 

CATALOG ,TAPE47 ,ORDERSDHHMM , I D=WDNAI 4CC , RP=999 
COMMENT.  +++++++++++  NEW  ORDERS  FILE 

COMMENT. ******************************************************************* 
COMMENT.  INPUT  DATA 

COMMENT  ******************************************************************* 
7/8/9  END  OF  RECORD  (JCL) 

INITIAL  DIRECTIVES 

6/7/B/9  END  OF  FILE  (USER  DIRECTIVES) 


Figure  16.  JCL  for  TRACE  MITL  processing. 


MAN-IN-TH  E-LOOP  (MITD/ORDERS  GENERATION 


Figure  17.  Man-in-the-loop  orders  generation  process. 


COMMENT. 


STEP  1  -  GET  THE  NECESSARY  FILES 


The  first  step  in  the  MITL  processing  is  to  attach  or  reserve  (as 
a  local  file)  all  of  the  necessary  program  and  data  files. 

ATTACH,  TUB,  TRACELIB , ID=WDNA14CC. 

Attaches,  as  a  local  file,  the  user  library  TRACELIB,  which 
contains  the  compiled  versions  of  the  approximately  450  TRACE  subprograms. 
The  system  loaders  will  locate  the  routines  needed  for  the  simulation  from 
the  library. 

ATTACH , TAPE3 , ISPACES , ID=WDNA14CC. 

COMMENT.  ++++++ 

Attaches  the  file  containing  the  ISPACEs  from  some  previous 
execution  or  initialization  run.  The  name  of  the  file,  underscored  by 
"++++",  is  the  same  that  was  used  to  catalogue  the  ISPACE  file  in  the 
previous  run.  It  is  usually  of  the  form  ISPACEDHHMM. 

REQUEST .TAPE47 ,*PF 

Reserves  permanent  file  space  for  the  orders  that  will  result 
from  the  processing  of  the  MITL  directives. 

ATTACH , MITL , TRACEMITL , ID=WDNA1 4CC . 

Attaches  the  compiled  version  of  the  main  MITL  processing  pro¬ 
gram.  This  program  drives  the  processing  of  the  MITL  directives.  It  is 
kept  in  a  separate  file  from  the  user  library  since  the  library  is  designed 
for  subprograms  and  not  main  programs. 

COMMENT.  STEP  2  -  PROCESS  MITL  DIRECTIVES 

LIBRARY, TLIB. 

The  computer  operating  system  is  informed  that  the  file  TLIB  is  a 
user  subprogram  library.  This  library  provides  all  TRACE  subprograms  other 
than  the  main  programs  and  some  FORTRAN  system  routines. 
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LD$ET,PRESET=ZERO. 

The  loader  is  instructed  to  preset  all  non-initial ized  memory 
locations  to  zero  when  the  TRACE  program  is  loaded  for  execution. 

MITL. 

The  loader  is  instructed  to  load  and  execute  the  MITL  processing. 
The  main  program  is  loaded  from  the  file  MITL  and  all  other  routines  are 
taken  from  the  TLI8  user  library  or  the  FORTRAN  system  library. 

COMMENT.  STEP  3  -  SAVE  GENERATED  ORDERS 

CATALOG , TAPE47 .ORDERSDHHMM , ID=WDNA1 4CC , RP=999 . 

COMMENT.  +++++++++++ 

Saves  the  file  containing  the  orders  generated  from  the  MITL 
directives.  The  "++++"  underscores  the  name  used  to  catalogue  the  file. 
DHHMM  indicates  the  time  in  the  ISPACES  file  to  which  the  orders  are  hook. 
This  time  is  important  because  there  is  a  high  degree  of  dependancy  in  the 
order  on  the  memory  layout  pictured  in  the  ISPACES  file,  at  the  time  point 
chosen. 

COMMENT.  INPUT  DATA 

(The  MITL  directives  are  explained  in  Section  2.) 

3.4  SIMULATION  EXECUTION 

The  TRACE  execution  phase  consists  of  a  series  of  combat  simu¬ 
lations  for  specified  periods  of  time.  At  the  beginning  of  each  of  these 
simulations,  new  operations  orders  for  both  Red  and  Blue  are  input.  See 
section  2.4.1  for  a  description  of  this  input.  At  the  end  of  each  simu¬ 
lation  period,  the  results  are  analyzed,  and  decisions  are  made  concerning 
the  orders  for  the  next  period. 

Each  simulation  in  this  execution  phase  begins  with  an  ISPACE  and 
ends  with  an  updated  ISPACE.  Multiple,  intermediate  ISPACEs  may  also  be 
saved.  The  ISPACE  is  the  dynamic  storage  array  containing  all  the  data  and 
list  structures  which  determine  the  current  status  of  the  simulation.  The 


56 


r 


combat  simulation  can  be  stopped  at  any  point  in  time  and  restarted  again 
by  saving  this  ISPACE  array  and  then  reloading  it  later. 

Figure  18  lists  the  JCL  necessary  for  each  simulation  in  the 
execution  phase  while  Figure  19  depicts  this  process.  The  remainder  of 
this  section  provides  a  detailed  explanation  of  each  JCL  step. 

JCL  EXPLANATION  (EXECUTION  PHASE) 


JOB  CARD. 

ACCOUNT  CARO. 

The  job  and  account  card  formats  for  the  AFWL  computer  system  are 
described  in  AFWL's  system  bulletins  (SYSBULLs).  It  is  important  to  note 
that  the  TRACE  simulation  uses  approximately  30  to  65  thousand  words  of 
Cyber  176  large  core  memory  (LCM),  depending  on  the  scenario.  Hence,  the 
job  card  should  contain  the  appropriate  EC  or  EL  parameters  to  inform  the 
system  that  LCM  will  be  needed. 

COMMENT.  STEP  1  -  GET  FILES  NECESSARY  FOR  TRACE  SIMULATION 

The  first  step  in  the  simulation  process  is  to  attach  or  reserve 
(as  local  files)  all  of  the  necessary  data  and  program  files. 

COPYBR, INPUT ,TAPE24. 

REWIND, TAPE24. 

Get  the  first  file  record  off  the  input  (up  to  100  cards  or 
logical  records)  and  copy  it  to  file  TAPE24.  This  file  contains  the 
description  of  this  execution.  The  file  is  then  rewound  for  use. 

ATTACH , TL I B , TRACE  L IB , I D=WDNA 14CC. 

Attaches,  as  a  local  file,  the  user  library  TRACELIB,  which 
contains  the  compiled  versions  of  the  approximately  450  TRACE  subprograms. 
The  system  loader  will  locate  the  routines  needed  for  the  simulation  from 
this  user  1 ibrary. 
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JOB  CARD 
ACCOUNT  CARD 

COMMENT .  ***********■*■********'*’*'*★★*■*************'*’****'*****'*  ★★★★★★★★★★★★  ★★★★★ 
COMMENT.  TRACE  SIMULATION  EXECUTION 

COMMENT . ******* ★★★★ *★* ★★★★★★★**★★★★★•*★★★★★★★★★★★★ ★★★★ ★★★★★★★★ *★★★ ★★★★★★★★★★★ 

COMMENT.’ . — . 

COMMENT.  STEP  1  -  GET  FILES  NECESSARY  FOR  TRACE  SIMULATION: 

COMMENT.  TAPE3  -  LAST  ISPACE  FROM  PREVIOUS  RUN 

COMMENT.  TAPE2  -  STATISTICS  FILE  FOR  POST  PROCESSOR 

COMMENT.  TAPE9  -  MITL  ORDERS  FILE 

COMMENT.  TAPE24  -  RUN  DESCRIPTION 

COMMENT.  TAPE31  -  FILE  ON  WHICH  NEW  ISPACE  WILL  BE  WRITTEN 

COMMENT.  TLIB  -  TRACE  SUBPROGRAM  LIBRARY 

COMMENT.  TRACE  -  MAIN  PROGRAM  BINARY 

COMMENT. . 

COPYBR, INPUT ,TAPE24  GET  RUN  DESCRIPTION  ONTO  FILE 

REWIND, TAPE24.  REWIND  FILE 

ATTACH, TLIB, TRACELIB, ID=WDNA14CC.  GET  TRACE  SUBPROGRAM  LIBRARY 

ATTACH.TAPE9 .ORDERSDHHMM, IDSWDNAI4CC .  GET  ORDERS  FILE 

COMMENT.  +++++++++++  NAME  OF  ORDERS  FROM  MITL 

ATTACH, TAPE3, ISPACES ,ID=WDNAI4CC.  GET  OLD  ISPACES 

COMMENT.  +++++++  NAME  OF  ISPACES  FROM  PREVIOUS  RUN 

ATTACH ,TCOR .TRACEEXEC , I D=WDNA1 4CC .  GET  TRACE  BINARY 

REQUEST, TAPE3I ,*PF.  RESERVE  FILE  FOR  NEW  ISPACES 

REQUEST, TAPE2,*PF.  RESERVE  FILE  FOR  RUN  STATISTICS 

COMMENT. . 

COMMENT.  STEP  2  -  EXECUTE  TRACE  SIMULATION 

COMMENT. . 

LIBRARY, TLIB. 

LDSET,PRESET=ZERO. 

TRACE, PL=20000. 

COMMENT. . - . - . - . 

COMMENT.  STEP  3  -  SAVE  RESULTS  FROM  THIS  SIMULATION 

COMMENT. . - . — 

CATALOG, TAPE31 ,NEWISPACE,ID=WDNA14CC ,RP=999. 

COMMENT.  +++++++++  NAME  OF  NEW  ISPACES 

CATALOG .TAPE2 ,THISSTATFILE , ID=WDNA1 4CC ,RP=999 . 

COMMENT.  ++++++++++++  NAME  OF  RUN  STATISTICS  FILE. 

REWIND, TAPE55. 

COPY, TAPE55, OUTPUT.  COPY  SIGINT  INFORMATION  TO  OUTPUT 

REWIND, TAPE73. 

COPY, TAPE73, OUTPUT.  COPY  BLUE  MESSAGES  RECEIVED  TO  OUTPUT. 

COMMENT  ******************************************************************* 
COMMENT.  INPUT  DATA 

COMMENT . ******************************************************************* 
7/8/9  ’  END  OF  RECORD  (JCL) 

run  description 

7/8/9  END  OF  RECORD  (RUN  DESCRIPTION) 

EXECUTE  CODE  WORD  FOR  THE  EXECUTION 

user  directives 

6/ 7/8/9  END  OF  FILE  (USER  DIRECTIVES) 


Figure  18.  JCL  for  TRACE  execution  run. 
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Figure  19.  TRACE  model  execution  process. 


ATTACH , TAPES , ORDERSDHHMM , I D=WDNA 14CC. 

COMMENT.  +++++++++++ 

Attaches  the  file  containing  the  orders  from  a  MITL  processing. 
The  name  "ORDERSDHHMM",  underscored  by  "++++",  is  the  file  name  used  to 
catalog  the  orders  in  the  MITL  run.  The  DHHMM  refers  to  the  time  of  the 
ISPACE  to  which  the  orders  were  hooked  in  the  MITL  processing.  (See 
immediately  below  for  format  of  DHHMM.) 

ATTACH , TAPE3 , I SPACES , I D=WDNA 14CC. 

COMMENT .  +++++++ 

Attaches  the  file  containing  the  ISPACEs  from  some  previous 
execution  or  initialization  run.  The  name  "ISPACES",  underscored  with 
"++++"  for  user  convenience,  is  the  file  name  under  which  the  ISPACEs  were 
cataloged.  This  catalog  name  is  normally  a  name  of  the  form  ISPACEDHHMM, 
where  DHHMM  indicates  the  combat  simulation  time  at  which  the  run  put  the 
first  ISPACE  on  the  file: 

D  -  day  of  combat  (1-9) 

HH  -  hour  (00-23) 

MM  -  minute  (00-59) 

For  example,  if  the  name  of  the  last  ISPACE  was  ISPACE10800,  this  would 
indicate  that  a  prior  simulation  put  the  first  ISPACE  on  the  file  on  the 
first  day  of  combat,  and  hence,  this  next  simulation  run  would  begin  at 
that  time  or  some  later  time  if  any  more  timepoints  exist  on  the  file. 

ATTACH , TRACE , TRACEEXEC , ID=W0NA 1 4CC . 

Attaches  the  compiled  version  of  the  main  simulation  program. 
This  program  controls  the  execution  of  the  simulation.  It  is  kept  in  a 
separate  file  from  the  user  library,  since  the  library  is  designed  for 
subprograms  and  not  main  programs. 

REQUEST, TAPE2,*PF 

Reserves  permanent  file  space  for  the  history  statistics  that 
will  be  generated  by  this  run  and  saved  for  use  by  a  post  processor. 
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REQUEST, TAPE31 ,*PF. 

Reserves  permanent  file  space  for  the  new  ISPACE  that  will  be 
created  and  cataloged  by  this  simulation  run.  The  main  program  will  write 
the  new  ISPACE  to  this  file  at  the  end  of  the  run. 

COMMENT.  STEP  2  -  EXECUTE  TRACE  SIMULATION 

After  all  the  necessary  files  have  been  attached  or  reserved,  the 
following  instructions  begin  the  running  of  the  TRACE  simulation. 

LIBRARY, TLIB. 

The  operating  system  is  informed  that  the  file  TLIB  is  a  user 
subprogram  library.  This  library  provides  all  the  TRACE  subprograms  other 
than  the  main  programs  and  the  FORTRAN  system  routines. 

LDSET , PRESET=ZERO. 

The  loader  is  instructed  to  preset  all  non  initialized  memory 
locations  to  zero  when  the  TRACE  program  is  loaded  for  execution. 

TRACE, PL=20000. 

The  loader  is  instructed  to  load  and  execute  the  TRACE  simu¬ 
lation.  The  main  program  is  loaded  from  the  file  TRACE,  while  all  other 
routines  are  loaded  from  the  TLIB  user  library  or  the  FORTRAN  system 
library.  The  PL=20000  parameter  sets  the  system  print  line  limit  to  20,000 
lines  of  output.  If  the  simulation  generates  more  than  this  number  of 
lines,  an  error  will  occur  and  the  program  will  abort. 

COMMENT.  STEP  3  -  SAVE  RESULTS  FROM  THIS  SIMULATION 

When  this  run  is  complete,  history  statistics  and  updated  ISPACEs 
may  be  saved,  and  the  Blue  message  file  and  Red  SIGINT  file  are  copied  to 
the  1 ine  printer. 
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CATALOG , TAPE2 , THISSTATFItE , ID=WDNA14CC , RP=999. 

COMMENT.  ++++++++++++  NAME  OF  RUN  STATISTICS  FILE 

Saves  the  file  containing  the  history  statistics  if  one  is  gen¬ 
erated  by  this  run.  (See  user  directives,  Section  2.)  The  "++++"  under¬ 
scores  the  name  under  which  this  file  is  saved.  This  name  is  usually  of 
the  form  TRACEOHHMMJJJ.  The  OHHMM  is  the  same  as  for  the  ISPACE  file.  JJJ 
is  the  Julian  date  the  simulation  was  run.  RP=999  indicates  an  indefinite 
retention  period. 

CATALOG , TAPE31 , NEWISPACE , ID=WDNA1 4CC , RP=999 . 

COMMENT.  +++++++++ 

Saves  the  file  containing  the  ISPACEs  updated  by  this  simulation 
run.  This  file  will  be  generated  only  if  the  user  directs.  See  descrip¬ 
tion  of  user  directives  in  Section  2.  The  underscores  for  user 

convenience  the  name  under  which  this  file  will  be  saved.  This  catalog 
name  is  usually  of  the  form  ISPACEDHHMM,  as  described  above  (see  explana¬ 
tion  of  ATTACH, TAPE3,  LASTISPACE,  .  .  .  instruction).  The  RP=999  parameter 
indicates  the  file  is  to  be  saved  indefinitely.  If  this  parameter  is  ieft 
out,  the  file  will  be  saved  for  the  system  default  length  of  time  (cur¬ 
rently  10  days)  and  then  discarded. 

REWIND, TAPE73. 

COPY, TAPE73, OUTPUT. 

TRACE  builds  a  local  file,  TAPE73,  containing  a  copy  of  all  the 
messages  received  by  BLUE  commanders.  At  the  end  of  the  simulation,  this 
file  is  rewound  and  copied  to  the  line  printer.  See  section  4.3  for  an 
explanation  of  this  information. 

REWIND, TAPE55. 

COPY, TAPE55, OUTPUT. 

The  TRACE  simulation  writes  signal  intelligence  and  direction 
finding  information  to  the  local  file  TAPE55.  At  the  end  of  the  simula¬ 
tion,  the  file  is  reset  to  the  beginning  of  written  information,  and  then 


copied  to  the  line  printer.  See  section  4.4  for  a  description  of  this 
SIGINT  output. 

COMMENT.  INPUT  DATA 

As  the  TRACE  simulation  begins  execution,  two  input  sets  are 
read.  These  input  sets  are  separated  by  the  end  of  record  markers  (a  card 
with  7/8/9  punched  in  the  first  column),  and  are  read  in  the  order  shown  in 
Figure  18. 

The  first  input  set  is  a  user  supplied  run  description  or  title 
page  for  the  simulation  output.  TRACE  reads  and  prints  card  images  until 
it  reaches  an  end  of  record.  The  user  can  include  comments  here  that  will 
provide  information  on  this  particular  simulation  run.  This  can  be  up  to 
100  cards  and  will  be  stored  with  the  POST  PROCESSOR  file  if  one  is  gen¬ 
erated. 

The  second  input  set  begins  with  a  card  with  the  word  EXECUTE  in 
columns  1-7.  This  is  the  code  for  an  execution  of  TRACE.  Following  this 
card  are  the  user  directives  as  explained  in  Section  2.5. 

3.5  TRACE  POST  PROCESSOR 

A  history  statistics  file  may  be  generated  by  user  di recti ved 
during  each  run  of  the  TRACE  simulation.  This  file  is  stored  and  a  selec¬ 
tion  of  output  may  be  generated  from  it  at  a  later  date.  The  generation  of 
these  outputs  is  detailed  in  Chapter  4. 

Figure  20  lists  the  JCL  needed  to  run  this  post  processor  and  the 
remainder  of  this  section  explains  the  JCL  in  detail.  Figure  21  depicts 
this  processing. 

JCL  EXPLANATION  (POST  PROCESSOR) 


JOB  CARO. 

ACCOUNT  CARD. 

The  job  and  account  card  formats  for  the  AFWL  computer  system  are 
described  in  AFWL's  system  bulletins  (SYSBULLs).  It  is  important  to  note 
that  the  TRACE  simulation  uses  approximately  30  to  65  thousand  words  of 
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JOB  CARD 
ACCOUNT  CARO 

COMMENT .  ***************  ★★★*★★★★★*★★★★★★★★★★*★  ★★★★★  ★★★★  *★★★★★  ★★★★★★★*★★*★★★★  ★★ 
COMMENT.  TRACE  POST  PROCESSOR 

COMMENT .  *************************★***************************★■*■*'*■*’'*'★'*•■*■★★★★★ 

comment! . - . - . . 

COMMENT.  STEP  1  -  GET  NECESSARY  FILES 

COMMENT. . . . - . - . . 

ATTACH, TUB, TRACELIB, ID=W0NA14CC.  GET  TRACE  SUBPROGRAM  LIBRARY 

ATTACH, POST, TRACEPOSTPROC, I0=W0NA14CC.  GET  TRACE  POST  PROCESSOR  BINARY 
ATTACH ,TAPE1 .OLDSTATFILE , ID=WDNA1 4CC.  GET  A  HISTORY  STATISTICS  FILE 
COMMENT.  +++++++++++  NAME  OF  STATISTICS  FILE 

COMMENT. . - . — . — . . 

COMMENT.  STEP  2  -  PROCESS  USER  REQUESTS 

COMMENT. . . . — . — 

LIBRARY, TLIB. 

POST,PL=40000 . 

COMMENT. . - . - . - . - . 

COMMENT.  INPUT  DIRECTIVES 

COMMENT. . - . - . - . - 

7/8/9  END  OF  RECORD  (JCL) 

user  directives 

6/7/8/9  END  OF  FILE  (USER  DIRECTIVES) 


Figure  20.  JCL  for  TRACE  post  processor. 
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TRACE  POST  PROCESSOR 


USER  INPUT  PROCESSING  TEMPORARY  PERMANENT 

FILES  FILES 


Figure  21.  TRACE  post  processing  process. 
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Cyber  176  large  core  memory  (LCM),  depending  on  the  scenario.  Hence,  the 
job  card  should  contain  the  appropriate  EC  or  EL  parameters  to  inform  the 
system  that  LCM  will  be  needed. 

COMMENT.  STEP  1  -  GET  NECESSARY  FILES 

The  first  step  is  to  attach  the  necessary  program  and  data  files. 

ATTACH , TLIB , TRACELIB , ID=WDNA 1 4CC . 

Attaches,  as  a  local  file,  the  user  library  TRACELIB,  which 
contains  the  compiled  versions  of  the  approximately  450  TRACE  subprograms. 
The  system  loader  will  locate  the  routines  needed  for  the  simulation  from 
the  user  1 ibrary. 

ATTACH , POST , TRACEPOSTPROC , I D=WDNA 1 4CC . 

Attaches  the  compiled  version  of  the  main  processing  program. 
This  program  chooses  which  subprograms  to  activate  to  handle  each  of  the 
user  directives.  It  is  kept  on  a  separate  file  from  the  user  library  since 
the  library  is  designed  for  subprograms  not  main  programs. 

ATTACH .TAPEl .OLDSTATFILE , ID=WDNA14CC. 

COMMENT.  +++++++++++ 

Attaches  the  file  containing  the  history  statistics.  This  file 
was  generated  by  some  previous  execution  of  the  TRACE  simulation.  The  file 
name,  underscored  by  "++++",  is  usually  in  the  form  TRACEDHHMMJJJ.  DHHMM 
is  the  first  time  point  that  appears  on  the  file.  JJJ  is  the  Julian  date 
that  the  file  was  created. 

COMMENT.  STEP  2  -  PROCESS  USER  REQUESTS 

LIBRARY, TLIB. 

The  computer  operating  system  is  informed  that  the  file  TLIB  is  a 
user  subprogram  library.  This  library  provides  all  TRACE  subprograms  other 
than  the  main  programs  and  some  FORTRAN  system  routines. 
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POST,PL=40000. 

The  loader  is  instructed  to  load  and  execute  the  post  processor. 
The  main  program  is  loaded  from  the  file  POST  and  all  other  routines  are 
loaded  from  the  TLI8  user  library  or  the  FORTRAN  system  library.  The  PL= 
40000  parameter  instructs  the  system  to  set  the  print  line  limit  to  40,000 
line  of  output.  This  is  large  due  to  the  tabular  nature  of  the  output.  It 
may  be  reduced  once  a  standard  pattern  of  user  directives  is  established 
for  a  particular  user. 

COMMENT.  INPUT  DIRECTIVES 

The  user  directives  may  come  in  any  order  and  are  described  in 


Section  4. 


SECTION  4 

SIMULATION  OUTPUTS 


4.1  INTRODUCTION 

During  the  execution  of  a  TRACE  simulation  run,  four  different 
types  of  output  are  generated: 

(1)  A  running  commentary  of  significant  events  occurring  during 
the  simulation  including  the  status  of  the  unit  affected; 

(2)  Overall  status  summaries  of  Red  and  Blue  forces  down  to 
battalion  or  company  level; 

(3)  Blue  messages  received; 

(4)  Signal  intelligence  and  direction  finding  information 

obtained  by  Red  forces. 

After  completion  of  a  TRACE  simulation  run,  a  post  processor  may 
be  applied  to  a  generated  file.  Four  types  of  outputs  are  available  from 
this  post  processor: 

(1)  Tables  of  message  statistics; 

(2)  Tables  of  unit  statistics; 

(3)  Hex  maps  of  a  snapshop  of  the  battlefield; 

(4)  Hex  maps  tracing  the  movement  of  designated  units. 

The  following  paragraphs  describe  each  of  these  output  types  in 
greater  detai 1 . 

4.2  RUNNING  COMMENTARY 

The  running  commentary  output  provides  a  detailed  chronological 
listing  of  major  events  occurring  during  a  TRACE  simulation  run.  Each  line 
of  the  commentary  identifies  a  specific  event  or  situation  and  the  unit 
involved.  If  the  unit  is  at  the  company  level,  its  commander  is  also 
identified.  In  addition,  the  unit's  position,  speed,  direction  of  move¬ 
ment,  and  materiel  on  hand  and  lost  are  indicated.  Some  of  the  comments 
are  not  printed  out  100%  of  the  time  that  the  corresponding  event  occurs. 
Instead  a  random  selection  of  these  events  is  chosen  to  be  printed,  based 
on  the  relative  importance  of  the  event. 
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Figure  22  shows  the  heading  which  appears  on  each  page  of  the 
running  commentary  output  and  a  few  sample  lines  of  this  output.  The  fol¬ 
lowing  information  is  printed  with  each  comment: 

1.  TIME  The  simulation  time  at  which  this  comment  was 

generated  is  expressed  in  the  format 
DHHMM:SS.  Here  D  indicates  the  day  of  the 
conflict  starting  with  day  1,  HH  indicates 
the  hour  using  a  24  hour  clock,  MM  indicates 
the  minute,  and  SS  indicates  the  second. 

2.  SIDE  This  is  either  RED  for  Warsaw  Pact  forces  or 

BL  (BLUE)  for  NATO  forces. 

3.  COMMANDER  The  command  unit  affected  by  this  event  or 

situation  is  identified  by  unit  number  and 
type.  The  possible  unit  types  are  listed 
with  the  description  of  the  input  language 
UOIL  in  Appendix  C.  The  command  unit  is 
always  at  the  battalion  level  or  above.  If  a 
company  level  unit  is  specified  under  COM¬ 
PANY,  it  is  a  subordinate  of  this  unit. 

4.  COMPANY  The  company  level  unit,  if  any,  affected  by 

this  event  or  situation  is  identified  by  unit 
number  and  type.  If  the  comment  pertains 
only  to  a  command  unit  and  to  no  particular 
company  level  subordinate,  this  section  is 
left  blank  and  the  position,  materiel  and 
movement  information  refers  to  the  command 
unit  specified  under  COMMANDER.  Otherwise, 
the  position,  materiel,  and  movement  infor¬ 
mation  pertains  to  the  company  level  unit 
specified  here. 

5.  POSITION  This  is  the  hex  address  of  the  unit  affected. 

For  a  description  of  hex  addresses  see 
Appendix  A. 
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Figure  22  shows  the  heading  which  appears  on  each  page  of  the 
running  commentary  output  and  a  few  sample  lines  of  this  output.  The  fol¬ 
lowing  information  is  printed  with  each  comment: 

1 .  TIME  The  simulation  time  at  which  this  comment  was 

generated  is  expressed  in  the  format 
DHHMM:SS.  Here  D  indicates  the  day  of  the 
conflict  starting  with  day  1,  HH  indicates 
the  hour  using  a  24  hour  clock,  MM  indicates 
the  minute,  and  SS  indicates  the  second. 

2.  SIDE  This  is  either  RED  for  Warsaw  Pact  forces  or 

BL  (BLUE)  for  NATO  forces. 

3.  COMMANDER  The  command  unit  affected  by  this  event  or 

situation  is  identified  by  unit  number  and 
type.  The  possible  unit  types  are  listed 
with  the  description  of  the  input  language 
UOIL  in  Appendix  C.  The  command  unit  is 
always  at  the  battalion  level  or  above.  If  a 
company  level  unit  is  specified  under  COM¬ 
PANY,  it  is  a  subordinate  of  this  unit. 

4.  COMPANY  The  company  level  unit,  if  any,  affected  by 

this  event  or  situation  is  identified  by  unit 
number  and  type.  If  the  comment  pertains 
only  to  a  command  unit  and  to  no  particular 
company  level  subordinate,  this  section  is 
left  blank  and  the  position,  materiel  and 
movement  information  refers  to  the  command 
unit  specified  under  COMMANDER.  Otherwise, 
the  position,  materiel,  and  movement  infor¬ 
mation  pertains  to  the  company  level  unit 
specified  here. 

5.  POSITION  This  is  the  hex  address  of  the  unit  affected. 

For  a  description  of  hex  addresses  see 
Appendix  A. 
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TANK 


The  number  of  tanks  the  affected  unit  has  on 
hand  (0/H)  and  has  lost  (L)  are  indicated. 
For  simulation  purposes  a  single  tank  is  a 
normalized  quantity  representing  approxi- 
matley  one  tank  with  crew. 

7.  INF  The  number  of  antitank  units  (ATU's)  the 

affected  unit  has  on  hand  (0/H)  and  has  lost 
(L)  are  indicated.  An  ATU  represents  approx¬ 
imately  one  infantry  squad. 

8.  TUBE  The  number  of  artillery  tubes  the  affected 

unit  has  on  hand  (0/H)  and  has  lost  (L)  are 
indicated.  A  single  tube  is  a  normalized 
quantity  representing  approximately  one  155mm 
gun  with  crew. 

9.  AMMO  This  lists  the  rounds  of  ammunition  the 

affected  unit  has  on  hand  (0/H)  and  has 
expended  (E). 

10.  SPO  The  current  speed  of  the  affected  unit  is 

given  in  kilometers  per  hour. 

11.  OIR  The  approximate  direction  of  movement  of  the 

affected  unit  is  indicated.  If  the  unit  is 
at  rest,  a  series  of  dashes  is  printed. 
Otherwise  the  direction  is  rounded  to  the 
nearest  of  the  16  basic  compass  directions: 

N,  NNE ,  NE,  ENE, 

E,  ESE,  SE,  SSE, 

S,  SSW,  SW,  WSW, 

W,  WNW,  NW,  NNW. 

12.  REMARKS  A  brief  comment  printed  here  identifies  the 

event  or  situation  which  has  occurred.  For  a 
complete  list  and  explanation  of  all  possible 
remarks  see  Appendix  B. 
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The  first  sample  comment  in  Figure  22  shows  that  the  3rd  Armored 
Brigade  on  the  Blue  side  received  a  status  report  from  a  subordinate  at 
approximately  0621  hours  on  the  first  day  of  the  conflict.  This  brigade 
was  located  at  hex  7777724  and  was  moving  at  a  rate  of  0.9  kilometers  per 
hour  in  a  southeasterly  direction.  So  far  it  had  expended  384  rounds  of 
ammunition  and  had  lost  1  tank  and  1  ATU. 

The  next  example  in  the  figure  indicates  that  the  131st  Tank 
Company  of  the  13th  Red  Tank  Battalion  has  just  advanced  west  southwest 
into  hex  777761535.  It  was  not  in  combat  and  had  suffered  no  losses  as  of 
0629  hours. 

At  0633  hours  the  312th  Mech  Company  of  the  31st  Blue  Mech  Bat¬ 
talion  had  lost  2  ATUs  and  had  11  remaining.  It  was  engaged  in  combat  and 
just  requested  conventional  artillery  fire  against  an  enemy  unit. 

The  final  two  comments  in  the  sample  output  in  Figure  22  indicate 
that  the  listed  units  have  just  suffered  casualties  due  to  enemy  close  air 
support  and  direct  ground  fire,  respectively. 

4.  3  STATUS  SUMMARIES 

At  periodic  intervals  the  TRACE  simulation  may  be  interrupted, 
according  to  user  directive,  to  print  out  complete  status  summaries  of  Red 
and  Blue  forces.  This  can  be  done  either  down  to  battalion  level  units 
only  or  all  the  way  down  to  company  level  units. 

The  status  summary  output  begins  with  a  heading  which  takes  the 

form: 


TIMEOUT  FOR  "side"  "level"  STATUS 

where  "side"  is  either  RED  or  BLUE,  and  "level"  is  either  BATTALION  or 

COMPANY.  Following  this  heading  appears  the  same  heading  as  on  each  page 

of  the  running  commentary.  Then  the  status  of  each  unit  at  or  above  the 

specified  level  of  command  is  indicated  in  the  running  commentary  format. 
Figure  23  shows  two  examples  of  status  summary  output  at  0750  hours  on  the 
first  day  of  the  conflict.  Red  status  is  shown  here  down  to  battalion 

level  units  and  Blue  status  down  to  company  level  units.  In  each  case  only 
the  first  several  lines  of  the  output  are  included  in  the  figure.  Note 
that  the  comment  appearing  in  the  REMARKS  column  is  always  PRESENT  STATUS. 
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Figure  23.  Example  status  sumnaries. 


4.4 


BLUE  MESSAGE  FILE 

TRACE  collects  a  copy  of  every  message  received  by  any  BLUE 
commander  and  displays  them  in  the  order  received.  A  listing  of  all  these 
messages  is  made  at  the  end  of  each  simulation  run.  For  each  message  there 
is  a  summary  of  the  characteristics  of  the  communications  net  over  which 
the  message  was  transmitted.  The  message  context  and  senders  location  are 
also  displayed.  Figure  24  is  a  sample  of  the  BLUE  message  file  output. 

4.4.1  Communication  Network  Character!" sties 

For  each  message  sent,  there  is  a  line  of  output  providing  all 
known  characteristics  of  the  communication  net.  The  following  is  a  list 
and  explanation  of  these  characteristics: 

(1)  Time  at  which  message  is  sent. 

Time  is  presented  in  the  standard  form  used  in  this 
simulation:  in  days,  hours,  and  minutes  (DHHMM)  -  one 
digit  for  the  day  of  combat,  two  digits  for  the  hour, 
and  two  digits  for  the  minute.  For  example,  the  time 
10629  represented  6:29  A.M.  on  the  first  day  of  combat. 

(2)  Transmission  frequency  of  communication  net  -  in  megahertz 
(MHZ). 

(3)  Transmission  mode  of  the  communication  net. 

VOICE,  teletype  (TTY),  or  facsimile  (FAX). 

(4)  Security  level  of  the  message. 

(5)  Net  command  level  and  traffic  type. 

This  information  is  provided  only  if  message  was 

transmitted  in  the  clear. 

Command  level  refers  to  echelon  of  the  net  control 

station: 
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Figure  24.  Example  Blue  message  file  output. 


Net  traffic  type  corresponds  to  tne  norma’  type  of 


message  sent  over  this  net: 

Command  Net  (CMQ) 

Adminstrative  Net  (ADMIN) 

Artillery  Requst  Net  (ARTY) 

Intelligence  Report  Net  (INTEL) 

Close  Air  Support  Request  Net  (CAS) 


Messenger  (No  net  was  available)  (MSNGR) 

(6)  Sender  and  receiver  of  message. 

The  unit  number  and  unit  type  of  sender  and  receiver  was 
listed.  For  example,  if  the  31st  Mechanized  Battalion  had 
sent  a  message  to  the  3rd  Armored  Brigade,  the  sender  and 
receiver  portion  of  the  output  would  be: 

//FROM:  31  MECHBN  //TO:  3  ARMBDE// 

The  following  is  an  example  of  a  message  transmitted  by  voice  at 
15.272  megahertz  over  the  Corps  Close  Air  Support  Request  Net  from  the  31st 
Mechanized  Battalion  to  the  5th  Corps. 

/ 1 0629/  15.272  MHZ/VOICE/CLEAR/NET:  COR  CAS  //FROM:  31  MECHBN  //TO:  5  CORPS// 
4.4.2  Message  Content 

In  addition  to  net  characteristics,  the  content  of  a  message  is 
output.  There  are  six  basic  types  of  messages  being  transmitted  in  TRACE 
(one  type,  the  logistics,  is  not  yet  implemented): 

(1)  Operations  orders  from  a  commander  to  his  subordinate 

An  operations  order  consists  of  a  directive  for  a 
subordinate  to  either  attack  or  defend  a  certain  loca¬ 
tion  by  a  given  effective  time. 

Sample  output: 

OP  ORDER  :  DEFEND  OBJECTIVE  777772727  EFFECTIVE  TIME  10830 


This  is  an  operations  order  for  a  subordinate  tc  reach  and 
defend  the  location  777772727  by  8:30  A.M.  on  the  first  day 
of  the  war. 

Format: 

OP  ORDER  :  "ATTACK  OR  DEFEND"  OBJECTIVE  "Hex  Location11 
EFFECTIVE  TIME  "DHHMM" 

(2)  Status  reports  from  a  unit  to  his  commander. 

(a)  There  are  three  types  of  status  report:  period,  mis¬ 
sion  accomplishment,  and  situation  demanded. 

Periodical  ly ,  a  unit  will  send  a  status  report  to  his 
commander  to  inform  him  of  his  present  location  and  the 
compass  direction  (i.e.,  north(N),  south(S),  etc.)  in 
which  he  is  headed 

Sample  output. 

STATUS  REPORT:  BLU  31  MECHBN  LOCATED  77777264  HEADING  S 
This  is  a  status  report  from  the  BLUE  31st  Mechanized  Bat¬ 
talion  informing  his  commander  that  he  is  presently  located 
at  hex  77777264  heading  south. 

Format: 

STATUS  REPORT:  "side"  "Unit  Name"  LOCATED  "Hex 
Location"  HEADING  "Direction" 

(b)  Whenever  a  unit  reaches  its  objective  the  commander 
will  be  informed  so  that  the  progress  of  the  battle  can 
be  monitored 

Sample  output:  STATUS  REPORT:  BLU  42  RECBN  REACHED 
OBJ  77777246 

This  is  a  status  report  from  the  BLUE  42nd  Reconnais- 
sence  Battalion  informing  his  commander  that  he  has 
reached  the  objective  at  hex  77777246. 

Format: 

STATUS  REPORT:  "Side"  "Unit  Name"  REACHED  OBJ 
"Hex  Location" 


77 


(c)  Whenever  a  unit  perceives  the  death  or  total  destruc¬ 
tion  of  another  unit,  it  sends  a  "situation  demanded" 
status  report  to  his  commander  to  inform  him  of  the 
fact. 

Sample  Output: 

STATUS  REPORT:  BLU  721  ARMCO  DIED  IN  HEX  777772651 
This  is  a  status  report  stating  that  the  BLUE  721st 
Armored  Company  was  seen  to  be  destroyed  in  hex 
777772651. 

Format: 

STATUS  REPORT:  "Side"  "Unit  Name"  DIED  IN  HEX  "Hex 
Locati on" 

(3)  Artillery  support  request  from  a  unit  to  an  artillery  bat- 
tal ion 

When  a  unit  gets  into  combat  he  will  request  his 
general  support  artillery  battalions  to  provide 
indirect  artillery  fire  agavnst  an  area  where  enemy 
units  are  located. 

Sample  output: 

ARTY  REQUEST  :  SHOOT  AT  -  777772665 

This  is  a  support  request  for  indirect  artillery  fire 
against  enemy  units  located  at  hex  777772665. 

Format: 

ARTY  REQUEST  :  SHOOT  AT  -  "Hex  Location" 

(4)  Intelligence  report  from  a  unit  to  his  commander 

When  a  unit  sees  an  enemy  unit,  he  will  send  a  report 
to  his  commander  informing  him  of  the  size,  type, 
location,  and  movement  direction  of  the  enemy  unit. 

Sample  output: 

INTEL  REPORT  :  RED  TKBN  LOCATED  77777256  HEADING  W 
This  is  an  intelligence  report  to  the  unit's  commander 
informing  him  that  the  unit  has  sighted  a  RED  tank 
battalion  which  is  presently  located  at  hex  77777267 
and  heading  in  a  westerly  direction. 
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Format: 

INTEL  REPORT: 


"Side"  "Unit  Type"  LOCATED  "Hex  Location" 
HEADING  "Compass  Direction" 


(5)  Close  air  support  request  from  a  unit  to  the  corps  airbase 

When  a  unit  is  in  combat,  he  will  request  close  air 
support  against  an  area  in  which  enemy  units  are 
located. 

Sample  output: 

CAS  REQUEST  :  ATTACK  ENEMY  UNIT  AT  -  777772667 

This  is  CAS  request  for  supporting  fire  at  hex 

777772667. 

Format: 

CAS  REQUEST  :  ATTACK  ENEMY  UNIT  AT  -  "Hex  Location" 

4.4.3  Sender  Location  and  Transmission  Time 

The  location  of  the  sender  and  time  of  initiation  of  transmission 
are  both  displayed  for  each  message 
Sample  output: 

SENT  FROM  UNIT  AT  HEX  77777631  AT  TIME  10051 

The  sender  of  this  message  was  located  in  hex  77777631  at 

10051  when  he  sent  the  message.  The  time  is  in  the  DHHMM 

format.  (DHHMM  format  is  explained  in  section  4.4. 1(1) 

above). 

Format: 

SENT  FROM  UNIT  AT  HEX  "Hex  Location"  AT  TIME  "DHHMM" 

4.5  SIGNAL  INTELLIGENCE 

TRACE  is  presently  designed  to  simulate  Red  SlGINT  operations 
against  Blue  communication  networks.  A  listing  of  all  Blue  messages 
intercepted  by  Red  listening  units  is  made  at  the  end  of  each  simulation 
run.  For  each  intercepted  message,  there  is  a  summary  of  the  characteris¬ 
tics  of  the  communication  net  over  which  the  message  was  transmitted.  In 
addition,  a  list  of  the  message  contents  (if  known)  and  any  direction 
* ' ndi ng  information  are  listed.  Figure  25  is  a  sample  of  the  SIGINT  infor- 
**t • on  output. 
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4.5.1  Communication  Network  Characteristics 

For  each  intercepted  message,  there  is  a  line  of  output  providing 
all  known  characteristics  of  the  communication  net.  The  following  is  a 
list  and  explanation  of  these  characteristics: 

(1)  Time  at  which  message  was  intercepted. 

Time  is  presented  in  the  standard  form  used  in  this 
simulation:  in  days,  hours,  and  minutes  (DHHMM)  -  one 
digit  for  the  day  of  combat,  two  digits  for  the  hour, 
and  two  digits  for  the  minute.  For  example,  the  time 
10629  represents  6:29  A.M.  on  the  first  day  of  combat. 

(2)  Transmission  frequency  of  communication  net  -  in  megahertz 
(MHZ). 

(3)  Transmission  mode  of  the  communication  net. 

VOICE,  teletype  (TTY),  or  facsimile  (FAX). 

(4)  Security  level  of  the  message.  For  the  present  "CLEAR"  will 
be  printed. 

(5)  Net  command  level  and  traffic  type. 

This  information  is  provided  only  if  message  was  trans¬ 
mitted  in  the  clear. 

Command  level  refers  to  echelon  of  the  net  control 
station: 

Corps  (COR) 

Division  (DIV) 

Brigade  (BDE) 

Battalion  (BN) 

Net  traffic  type  corresponds  to  the  normal  type  of 


message  sent  over  this  net: 

Command  Net  (CMD) 

Administrative  Net  (ADMIN) 

Artillery  Request  Net  (ARTY) 

Intelligence  Report  Net  (INTEL) 

Close  Air  Support  Request  Net  (CAS) 

Messenger  (no  net  was  available)  (MSNGR) 


•  >  •• 
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(6)  Sender  and  receiver  of  message. 

The  unit  number  and  unit  type  of  sender  and  receiver  are 
listed.  For  example,  if  the  31st  Mechanized  Battalion  had 
sent  a  message  to  the  3rd  Armored  Brigade,  the  sender  and 
receiver  portion  of  the  intercept  output  would  be: 

//FROM:  31  MECHBN  //TO:  3  ARMBDE// 

The  following  is  an  example  of  intercept  resulting  from  a  message 
transmitted  by  voice  at  15.272  megahertz  over  the  Corps  Close  Air  Support 
Request  Net  from  the  31st  Mechanized  Battalion  to  the  5th  Corps. 

/10629/  15.272  MHZ/VOICE/CLEAR/NET:  COR  CAS  //FROM:  31  MECHBN  //TO:  5  CORPS// 

4.5.2  Message  Content 

The  message  content  is  displayed  in  the  same  fashion  as  that  for 
the  BLUE  Message  File.  See  section  4.4.2  above  for  a  detailed  explanation. 

4.5.3  Radio  Direction  Finding  Information 

As  messages  are  transmitted  over  the  BLUE  communication  networks, 

RED  radio  direction  finding  units  attempt  to  determine  the  locations  of  the 
senders  of  these  messages.  If  a  successful  DF  fix  is  made  on  a  message 
sender,  the  location  of  the  communication  equipment  is  listed  along  with 
any  network  and  content  information  obtained  from  this  message. 

Sample  output: 

DF  :  SENDER  LOCATED  AT  777772245 

DF  information  obtained  from  an  intercepted  message  indi¬ 
cates  that  a  message  was  transmitted  from  communication 
equipment  located  at  777772245;  the  frequency  of  the  mes¬ 
sage,  sender,  receiver,  etc. ,  would  be  indicated  in  the 
network  characteristics  and  message  content  lines. 

Format: 

DF  FIX  :  SENDER  LOCATED  AT  "Hex  Location" 

4.6  POST  PROCESSOR  OUTPUTS 

This  section  will  also  define  the  inputs  or  user  directives 
needed  to  request  each  type  of  output.  User  directives  may  be  in  any 
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quantity  and  in  any  order.  However,  the  greatest  efficiency  is  gained  when 
the  time  points  used  in  one  output  do  not  overlap  those  used  in  the  next. 

An  important  concept  throughout  the  outputs  is  that  of  the  "time- 
interval".  Every  display  is  requested  in  relation  to  intervals  rather  than 
times.  The  interval  between  data  points  is  fixed  at  the  time  of  the  TRACE 
simulation  execution. 

4. 6. 1  Message  Tables 

The  message  table  is  a  ten-column  table  displaying  information  on 
each  of  the  messages.  An  example  appears  in  Figure  26.  For  each  message 
type  there  are  12  entries. 

(1)  Number  transmitted:  After  the  name  of  the  message  type  is 
displayed,  the  number  of  messages  of  that  type  transmitted 
during  the  interval  ending  at  the  time  displayed  in  column 
heading. 

(2)  Number  transmitted  via  a  command  net  (Similar  to  #1). 

(3)  Number  transmitted  via  an  administrative  net.  (Similar  to 

#1). 

(4)  Number  transmitted  via  an  artillery  net.  (Similar  to  #1). 

(5)  Number  transmitted  via  an  intelligence  net.  (Similar  to  #1). 

(6)  Number  transmitted  via  a  CAS  net.  (Similar  to  #1). 

(7)  Number  transmitted  by  a  courier.  (Similar  to  #1). 

(8)  Number  of  messages  transmitted  in  the  interval  that  were 
intercepted  (by  either  side.) 

(9)  Number  of  messages  whose  sender  was  located  by  enemy  direc¬ 
tion  finding  (DFed) 

(10)  Number  of  messages  whose  sender  was  attacked  by  indirect 
artillery  fire  after  they  were  DFed. 

(11)  Average  transmission  time  per  messages  (TOT-TOR)  in  seconds. 

(12)  Average  message  processing  time  (T0S-T0R)  in  seconds. 

The  directive  to  display  this  output  is  in  the  form: 

Card  Column  —  123  7  16 

OWI IXXTTTTTTTTTT 
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where  0  is  the  type  of  output  and  appears  in  column  1.  In  this 
case  the  entry  will  be  "M"  to  signify  the  message 
table. 

W  is  which  side  the  data  is  to  be  for.  It  will  be  "R" 
for  RED  message  data  (not  implemented  at  this  time)  and 
"8"  for  BLUE. 

II  is  the  inter-interval  display  lapse.  It  is  an  integer 
asking  for  every  nth  interval  to  be  displayed  (up  to  10 
on  one  table):  e.g. ,  02  displays  every  second  inter¬ 
val.  There  is  no  summing  between  intervals.  If 

insufficient  intervals  exist,  the  right  most  will  be 
blank. 

XX  are  columns  to  be  ignored  for  this  output  type. 

TTTTTTTTTT  is  a  10  place  real  number  with  no  assumed  deci¬ 
mals.  It  gives  the  time  point  (in  seconds)  which  is  to 
comprise  the  first  table  of  the  output.  If  exactly 
this  time  point  is  not  on  the  file,  the  first  one 
greater  will  be  used. 

Each  message  table  generates  exactly  two  pages. 

4.6.2  Unit  Status  Tables 

The  unit  status  tables  are  ten  column  tables,  each  two  pages 
long.  Eight  units  are  displayed  on  each  table  and  as  many  tables  as  nec¬ 
essary  are  generated  to  display  all  the  units  requested  by  the  user.  An 
example  of  this  table  appears  in  Figure  27.  Note  the  last  entry,  the  73rd 
Armored  Cavalry  Team,  gets  killed  between  hours  2  and  3.  The  "DEAD"  mes¬ 
sage  is  used  for  any  unit  that  does  not  yet  exist  or  ceases  to  exist. 

Thirteen  entries  are  made  for  each  unit  at  each  interval.  These 
represent  the  status  of  the  unit  at  that  instant.  The  first  entry  for  each 
is  the  unit  number  and  the  second  is  the  unit  type.  Together  these  two 
identify  the  unit.  The  top  entry  in  Figure  27  is  for  the  911th  Battery 
which  is  a  battery  of  122mm  guns.  The  third  entry  is  the  hex  location  of 
the  unit.  The  remaining  entries  give  the  quantity  on  hand  of  each  material 
type. 
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UNIT  STATUS  TABLE 

SIDE=RED  SMALLEST  UNIT  DISPLAYED=SECTION 

TIME  (IN  HOURS)  1.00  2.00  3.00  4.00  5.00 

******************************************************************************** 


A 

UNIT  NUMBR 

* 

911. 

911. 

911. 

911. 

911. 

* 

UNIT  NAME 

* 

BTY122 

BTY122 

BTY122 

BTY122 

BTY122 

A 

HEX  POSITN 

* 

777761572. 

777761575. 

777761575. 

777761575. 

777761575. 

* 

INFANTRY 

it 

1. 

1. 

1. 

1. 

1. 

* 

ARMOR 

it 

0. 

0. 

0. 

0. 

0. 

A 

ARTILLERY 

it 

6. 

6. 

6. 

6. 

6. 

A 

ROCKETS 

it 

0. 

0. 

0. 

0. 

0. 

A 

GRNO  NUKES 

it 

0. 

0. 

0. 

0. 

0. 

A 

AIR  NUKES 

it 

0. 

0. 

0. 

0. 

0. 

it 

A  A 

it 

0. 

0. 

0. 

0. 

0. 

it 

AG 

it 

0. 

0. 

0. 

0. 

0. 

it 

DUAL  AA 

it 

0. 

0. 

0. 

0. 

0. 

it 

it 

AMMUNITION 

it 

it 

435. 

390. 

390. 

390. 

390. 

it 

UNIT  NUMBR 

it 

7. 

7. 

7. 

7. 

7. 

it 

UNIT  NAME 

it 

ACS 

ACS 

ACS 

ACS 

ACS 

it 

HEX  POSITN 

77777633. 

77777264. 

77777242. 

77777242. 

77777242. 

it 

INFANTRY 

it 

7. 

6. 

1. 

1. 

1. 

it 

ARMOR 

it 

0. 

0. 

0. 

0. 

0. 

it 

ARTILLERY 

it 

0. 

0. 

0. 

0. 

0. 

it 

ROCKETS 

it 

0. 

0. 

0. 

0. 

0. 

it 

GRND  NUKES 

it 

0. 

0. 

0. 

0. 

0. 

it 

AIR  NUKES 

it 

0. 

0. 

0. 

0. 

0. 

it 

AA 

it 

0. 

0. 

0. 

0. 

0. 

it 

AG 

it 

0. 

0. 

0. 

0. 

0. 

it 

DUAL  AA 

it 

0. 

0. 

0. 

0. 

0. 

it 

AMMUNITION 

it 

0. 

0. 

0. 

0. 

0. 

A 

it 

* 

UNIT  NUMBER 

73. 

73. 

0. 

0. 

0. 

* 

UNIT  NAME 

ACT 

ACT 

DEAD 

DEAD 

DEAD 

A 

HEX  POSITN 

it 

777761563. 

777761563. 

0. 

0. 

0. 

it 

INFANTRY 

it 

3. 

3. 

0. 

0. 

0. 

it 

ARMOR 

it 

0. 

0. 

0. 

0. 

0. 

it 

ARTILLERY 

it 

0. 

0. 

0. 

0. 

0. 

it 

ROCKETS 

it 

0. 

0. 

0. 

0. 

0. 

it 

GRND  NUKES 

it 

0. 

0. 

0. 

0. 

0. 

it 

AIR  NUKES 

A 

0. 

0. 

0. 

0. 

0. 

A 

AA 

A 

0. 

0. 

0. 

0. 

0. 

A 

AG 

A 

0. 

0. 

0. 

0. 

0. 

A 

OUAL  AA 

A 

0. 

0. 

0. 

0. 

0. 

A 

AMMUNITION 

A 

141. 

251. 

0. 

0. 

0. 

Figure  27.  Example  unit  status  table  output. 


At  the  top  of  the  table  are  two  important  entries.  The  first, 
SIDE,  tells  which  side's  units  are  being  displayed.  The  second,  SMALLEST 
UNIT  DISPLAYED,  shows  the  lowest  level  unit  that  can  appear  on  this  table. 
In  the  example,  the  table  shows  RED  units  and  no  unit  lower  than  section 
will  be  displayed.  (Actually  there  are  no  sections  or  platoons  so  company 
is  the  lowest  that  actually  appears.) 

The  directive  to  display  this  output  takes  the  form: 

Card  Column  ---  123  57  16 

OWI I LLTTTTTTTTTT 

where  0,W,II,  and  TTTTTTTTTT  are  the  same  as  for  the  message 
table  output,  except  that  "U"  will  be  used  for  0  to  signify  the  unit  status 
table. 

LL  is  an  integer  number  that  indicates  the  level  of  the 
lowest  unit  that  is  permitted  on  this  set  of  tables. 

Unit  tables  will  continue  to  be  generated  until  all  unit,  of  the 
appropriate  level,  on  the  chosen  side  have  been  displayed  once.  Each  table 
except  the  last  one  generates  exactly  two  pages.  The  final  one  will  be  as 
short  as  necessary. 

4.6.3  Snapshot  Maps 

Figure  28  shows  an  example  of  a  snapshot  map.  Each  set  of  maps 
is  accompanied  by  a  legend  as  shown  in  Figure  29.  This  legend  relates  each 
hex  pictured  with  a  hex  address  listed  at  the  left  of  the  diagram. 

The  map  shown  in  Figure  28  is  in  one  of  four  possible  formats. 
These  formats  are: 

RXB  All  Red  units  are  signified  by  an  "R",  Blue  units  by  a 

"B"  and  where  ever  units  of  the  two  sides  are  colocated 

an  "X"  is  used.  When  units  of  the  same  side  are  colo¬ 
cated  only  one  symbol  is  displayed 
RB  Similar  to  the  RXB  format  only  whenever  units  are 

colocated,  successive  units  are  placed  in  empty  adja¬ 
cent  point  positions  regardless  of  which  side  they 
belong  to.  When  all  8  adjacent  locations  have  been 

filled,  additional  colocated  units  are  simply  left  off 
the  map. 
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59>a  Figure  28.  Snapshot  map 


*81 G*DC  $J?f  HfS 


Map  legend 


IXA  'I his  is  the  same  as  the  RXB  format  only  the  letters  A-F 
are  used  to  differentiate  the  type  of  Blue  unit  being 
displayed  and  1-6  for  Red.  A  legend  as  shown  in  Figure 
30  is  displayed  for  this.  When  units  of  the  same  side 
are  colocated  only  one  is  displayed. 

IA  This  is  the  same  as  the  RB  using  the  display  scheme  of 
the  IXA.  Figure  28  is  in  IA  format. 

Snapshot  maps  are  produced  over  a  range  of  times.  Each  map 
requires  exactly  one  page.  An  additional  page  is  used  for  the  legend  to 
accompany  the  series.  The  directive  to  display  this  output  is  in  the  form: 

Card  Column  1  22  44 

123  5  7  7  79  12 

OFIILLTTTTTTTTTTEEEEEEEEEENNCCCCCCCCCCCCHH 

where  0,  II  and  TTTTTTTTTT  are  the  same  as  for  the 

message  table,  except  that  "P"  will  be  used  for  0 
to  signify  the  snapshots;  LL  is  the  same  as  for 
the  unit  table. 

F  is  the  format  choice:  1=1A,  2=1XA,  3=RB,  and 

4=RXB. 

EEEEEEEEEE  is  a  10  place  real  number  with  no  assumed  decimals 

which  gives  the  time  point  of  the  last  of  the 
series  of  snapshots 

NN  is  the  number  of  hexes  to  be  displayed.  There  are 

two  choices:  7  or  19.  Figure  28  shows  19  hexes. 
Had  the  choice  for  that  output  been  7,  only  the 
seven  center  hexes  of  the  map  would  have  been 
displayed.  However,  the  map  would  have  beer, 
enlarged  so  that  those  seven  hexes  would  fill  the 
same  area  on  the  page. 

CCCCCCCCCCCC  is  a  right  justified  integer  hex  address.  This  is 
the  address  of  the  hex  that  is  to  be  in  the  center 
of  the  map. 

HH  is  the  level  of  the  hexes  that  are  to  be  displayed. 
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4.6.4 


Uni t  Trace  Maps 

Unit  trace  maps  are  exactly  like  snapshot  maps  except  that  only 
one  unit  appears  on  it.  The  units  first  position  is  designated  by  an  "A", 
the  second  by  a  "B",  etc.  If  there  are  more  than  26  positions,  the  27th 
will  begin  at  "A"  again.  This  map  will  be  dynamically  placed  so  that  the 
center  hex  will  be  that  hex  that  the  unit  was  in  most  often.  A  legend,  as 
in  Figure  29,  will  accompany  the  map.  The  directive  for  this  output  is  in 
the  form: 

Card  Column  1  22  4445 

123  57  7  79  137  3 

OWIIAATTTTTTTTTTXXXXXXXXXXNNXXXXXXXXXXXXHHUUUUDDDDDDD 


where 


AA 

NN 


UUUU 


0000000 


0,  W,  II,  and  TTTTTTTTTT  are  the  same  as  for  the 
message  table,  except  that  "T"  will  be  used  for  0 
to  signify  the  unit  trace; 

is  the  level  of  the  hex/address  to  be  used  for 
positioning  the  unit  on  the  trace  map; 
and  HH  are  the  same  as  for  the  snapshot  maps. 
Note  that  there  is  no  endtime  specified.  Unit 
traces  maps  always  extend  to  the  end  of  the  file; 
is  a  integer  giving  the  unit  number.  If  the  121st 
tank  company  was  to  be  traced,  the  unit  number 
would  be  121 ; 

is  the  name  of  the  unit.  Permissible  names  are 
represents  a  blank)  shown  below: 


Level  3  units:  AAACTM 
AARMC0A 
AATKC0A 
ABTY152 
ABTY122 
A8TY1 75 
ABTY155 
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AMRLBTY 

AAHHTAA 

AAHHBAA 

AAHHCAA 

ARECCOA 

AAMRCOA 

AMEClOA 

COMPANY 

Level  4  units  AATK8NA 
AARTYBN 
AMRLBNA 
AARMBNA 
ARECBNA 

aaacsaa 

aamrbna 

AMECHBN 

AABTNAA 

Level  5  units  AARMBDE 
AAACRAA 

atkrgta 

AMRRGTA 

ADISCOM 

ARECRGT 

ARTYRGT 

DIVARTY 

BDE/RGT 

Level  6  units  AARMDIV 
MECHDIV 
ATKDIVA 
ACOSCOM 
CORARTY 
AADIVAA 

Level  7  units  TKAARMY 
ACORPSA 
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/  AD-A079  996  0DM  CORP  MCLEAN  VA 


TRACE  COMPUTER  MODEL  USER'S  SUIOE.(U) 

XT  79  D  L  PORTER*  R  H  SCHMIDT  DNAOO1-70-C-O175 

UNCLASSIFIED  IDN/0-7S-77S-TR  DNA-A351T-8D  „  ML 


2  -  2 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

1 

■ 

■ 

■ 

■ 

■ 

END 

:i  -  bo 

THE  FOLLOWING  ARE  SNAPSHOTS  FROM  0  TO 

OF  EVERY  1  TIME  POINTS 


3  LEVEL  UNITS  ARE  DISPLAYED 

SYMBOLS 

BLUE  UNIT  RED 

A  HQ  1 

B  INF  2 

C  ART  3 

D  TNK  4 

E  REC  5 

F  MISC  6 


Figure  30.  Symbol  legend  for  snapshot  maps. 
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4.  7 


Directives 

A  display  of  the  four  directive  forms  appears  in  Figure  31.  Due 
to  the  nature  of  the  input  means,  card  positions  not  carrying  data  must  be 
left  blank. 


- Carcl  Columns - 

llllim  112222222222333333333344444444445555 
12345678901234567890123456789012345678901234567890123 


OWIIXXTTTTTTTTTT  Message  Table 

OWIILLTTTTTTTTTT  Units  Status  Table 

OFIILLTTTTTTTTTTEEEEEEEEEENNCCCCCCCCCCCCHH  Snapshot  Map 

OWIIAATTTTTTTTTTXXXXXXXXXXNNXXXXXXXXXXXXHHUUUUDDDDDDD  Unit  Trace  Map 


Figure  31.  Summary  of  post  processor  directive  formats. 
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APPENDIX  A 

USER  GUIDE  TO  HEXAGONAL  COORDINATE  SYSTEM 


A. 1  INTRODUCTION 

The  purpose  of  this  appendix  is  to  give  a  brief  explanation  of 
the  Hexagonal  Coorcinate  System  (HECS)  used  in  TRACE.  For  a  more  detailed 
discussion,  including  the  rationale  for  using  this  coordinate  system,  the 
reader  is  referred  to  the  draft  technical  report,  "An  Integrated  Coordinate 
System  for  Combat  Modeling",  B0M/W-78-297-TR ,  19  May  1978. 

A.  2  STRUCTURE  OF  HECS 

The  Hexagonal  Coordinate  System  is  based  upon  the  concept  of 
tiling  the  plane  with  a  grid  of  regular  hexagons  and  aggregating  them  into 
successively  larger  clusters  of  7.  A  single  regular  hexagon  in  the  grid  is 
called  a  level  0  hex.  A  cluster  of  7  level  0  hexes,  one  regular  hexagon 
together  with  its  6  neighboring  hexagons,  is  called  a  level  1  hex.  This 
process  of  aggregation  can  be  iterated,  and  in  general  a  cluster  of  6  level 
n  hexes  surrounding  a  central  level  n  hex  forms  a  level  n  +  1  hex. 

The  higher  level  hexes  are  not  true  regular  hexagons,  but  they 
remain  approximately  hexagonal  in  shape.  Hexes  at  any  level  mesh  together 
to  tile  the  plane. 

A.  3  THE  TRACE  BATTLEFIELD 

The  TRACE  simulation  runs  on  a  battlefield  represented  by  a 
single  level  12  uex.  This  hex  contains  7  level  11  hexes,  each  of  which 
contains  7  level  10  hexes,  and  so  on  down  to  the  level  0  hexes,  which  are 
regular  hexagons.  The  grid  is  oriented  so  that  the  level  0  hexes  have  a 
pair  of  opposite  edges  running  west  to  east.  The  scale  of  the  battlefield 
is  determined  by  the  size  of  the  level  0  hexes,  which  are  approximately 
72.89  meters  across  (from  one  side  to  the  opposite  side). 

Each  unit  in  TRACE  is  located  in  a  hex  of  a  certain  level.  Units 
at  higher  levels  of  command  occupy  more  territory  and  are  placed  in  larger 
hexes.  Table  2  shows  the  various  command  levels  and  the  dimensions  of  the 
hexes  which  they  occupy. 
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Table  2.  Hexes  typically  occupied  by  various  command  levels. 


Command 

Hex 

Hex 

Hex 

Level 

Level 

Diameter 

Area 

Company 

3 

1.35  km 

1.6  km' 

Battal ion 

4 

3.57  km 

11 . 0  km' 

Brigade/Regiment 

5 

9.45  km 

77.3  km' 

Division 

6 

25.00  km 

541.3  km' 

Corps 

7 

66.14  km 

3788.9  km' 

A. 4  HEX  ADDRESSES 

A  hex  address  is  a  string  of  one  to  twelve  digits  which  identi¬ 
fies  a  specific  hex.  It  is  a  way  of  encoding  both  the  location  and  the 

level  of  a  hex.  Each  digit  in  a  hex  address  is  from  1  through  7  inclusive. 
The  leftmost  digit  identifies  which  of  the  7  level  11  hexes  contains  this 

hex.  If  there  are  no  further  digits,  then  the  hex  address  corresponds  to 

this  level  11  hex.  The  next  digit  identifies  which  of  the  7  level  10  hexes 
comprising  the  level  11  hex  contains  the  hex  in  question.  This  classifi¬ 
cation  procedure  continues  all  the  way  down  to  the  level  of  the  specified 
hex.  The  hex  address  of  a  level  0  hex  will  have  12  digits,  and  in  general 
the  following  equation  is  satisfied: 

L  ♦  0  =  12 

where  L  is  the  level  of  the  hex  and  0  is  the  number  of  digits  in  his  hex 
address. 

It  remains  to  describe  which  hex  is  given  which  number  in  a  clus¬ 
ter  of  7  hexes.  The  numbering  scheme  for  a  level  1  cluster  of  7  level  0 

hexes  is  shown  in  Figure  32.  Note  that  7  indicates  the  center  hex  and  1 

indicates  the  hex  directly  north  of  center.  The  rest  of  the  numbering 

scheme  is  chosen  for  computational  convenience.  The  numbering  scheme  for  a 
level  2  cluster  of  7  level  1  hexes  is  shown  in  Figure  33.  The  scheme  is 
essentially  the  same  except  that  there  has  been  a  slight  counterclockwise 
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rotation  of  the  positions  of  the  hexes  numbered  1  through  6.  For  clusters 
of  higher  and  higher  level  hexes,  the  same  numbering  scheme  is  used,  but 
the  relative  positions  of  the  outer  hexes  rotate  approximately  19  degrees 
counterclockwise  for  each  increase  in  level. 

Figure  34  illustrates  the  combined  numbering  scheme  for  level  0 
hexes  within  a  level  2  hex.  The  two  digits  shown  would  be  the  last  2 
digits  in  the  hex  addresses  for  these  level  0  hexes.  Note  that  the  shaded 
level  0  hex  is  numbered  35  because  it  is  in  the  5  position  within  the 
number  3  level  1  hex  in  the  level  2  cluster.  Figure  35  shows  a  few  sample 
hex  addresses  in  a  level  cluster.  Actually  each  address  would  be  preceded 
by  a  string  of  9  digits  identifying  the  particular  level  3  hex  illustrated. 

A.  5  HEX  DIRECTIONS 

Units  at  a  given  level  of  command  in  TRACE  occupy  hexes  of  a 
given  level  as  listed  in  Table  2.  Movement  is  always  in  the  direction  of 
one  of  the  six  surrounding  hexes  of  the  same  level.  The  directions  are 
identified  by  the  same  numbering  scheme  as  used  for  creating  hex  addresses. 
Thus,  at  each  level,  the  hex  direction  7  represents  a  null  direction  signi¬ 
fying  no  movement,  and  there  are  6  equally  spaced  hex  directions  numbered  1 
through  6.  At  level  0,  hex  direction  1  corresponds  to  north,  but  it  under¬ 
goes  a  counterclockwise  rotation  of  about  19  degrees  for  each  higher  level. 
Figures  36  through  40  illustrate  the  hex  directions  at  levels  3  through  7, 
and  Table  3  gives  the  corresponding  approximate  compass  directions  which 
appear  in  the  running  commentary  and  status  summary  outputs. 


Figure  34.  Combined  numbering  scheme  for  level  0  hexes 
within  a  level  2  cluster. 
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Table  3.  Correspondence  between  hex  directions  and  compass  headings 
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APPENDIX  B 

EXPLANATION  OF  RUNNING  COMMENTARY  REMARKS 


B.1  INTRODUCTION 

A  general  description  and  some  examples  of  the  running  commentary 
printed  out  during  a  TRACE  simulation  run  are  given  in  section  4.2.  This 
appendix  explains  the  meaning  of  the  comments  printed  under  the  heading 
"REMARKS".  In  addition,  the  name  of  the  subroutine  which  generates  the 
output  is  noted  in  parentheses  after  each  comment.  All  commentary  messages 
are  not  displayed  in  response  to  all  stimulus.  Some  are  only  displayed  a 
percentage  of  the  time.  The  current  percentage  is  given  in  the  parentheses 
along  with  the  subroutine  name.  Due  to  the  modular  construction  of  the 
METRIC  family  of  simulations  and  that  blocks  of  code,  developed  by  dif¬ 
ferent  teams,  are  often  transported  from  one  member  to  another;  discrep¬ 
ancies  in. message  abbreviations  sometimes  appear.  In  TRACE,  COM  and  CMD 
are  both  used  to  refer  to  the  command  communications  network. 

B.  2  LIST  OF  COMMENTS 

1.  AOMIN  NET-BUSY  W/BKD  (O-NETOPEN) 

This  comment  is  printed  when  a  unit  is  unable  to  transmit  a 
message  over  an  administrative  net  because  the  net  is  busy  with  a  back¬ 
ground  message  at  that  time.  This  is  one  of  a  series  of  comments  which  can 
apply  to  any  one  of  5  different  types  of  nets: 

ADMIN  NET  Administrative  net  for  status  reports 

ARTY  NET  Artillery  support  request  net 

CAS  NET  Close  air  support  request  net 

COM  NET  Command  net  for  operations  orders 

INTEL  NET  Intelligence  reporting  net 

Also,  there  are  5  possible  reasons  for  a  net  being  closed: 

BUSY  W/MSG  Another  message  is  currently  being  transmitted 

over  thi s  net. 

BUSY  W/BKD  Net  is  busy  processing  a  background  message.  A 

background  message  is  one  that  simulates  normal 
net  traffic.  The  percentage  of  time  a  net  is  busy 
with  background  is  an  input  specified  by  the  user. 
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INOPERABLE 


Either  the  receiver  or  sender  communication 
equipment  for  this  net  has  been  damaged. 

JAMMED  Net  transmission  frequency  is  currently  jammed. 

OUT/RANGE  Sender  and  Receiver  are  not  within  communication 

range  of  their  equipment  for  this  net. 

2.  ADMIN  NETBUSf  W/MSG  (O-NETOPEN)  See  comment  1. 

3.  ADMIN  NETIN0PERA8LE  (O-NETOPEN)  See  comment  1. 

4.  ADMIN  NET JAMMED  (O-NETOPEN)  See  comment  1. 

5.  ADMIN  NET-OUT/RANGE  (O-NETOPEN)  See  comment  1. 

6.  ADMIN  NET  SEC  BREAK  (100-INTRCPT) 

This  comment  will  be  printed  when  a  future  capability  is  imple¬ 
mented.  It  will  have  the  following  general  form: 

"net  type"  SEC  BREAK 

The  possible  net  types  are  the  same  as  those  listed  under  comment  1.  It 
will  signify  a  security  break  on  the  net. 

7.  ADMIN  NET-TRANSMIT  (30-TRNSMIT) 

This  comment  is  printed  periodically  when  a  unit  is  transmitting 
a  message  over  an  administrative  net.  The  general  form  of  this  type 
comment  is: 

"net  type"  -  TRANSMIT 

The  possible  net  types  are  the  same  as  those  listed  under  comment  1. 

8.  ARRIVE  AT  OBJ  (100-M0VMUZQ) 

This  comment  is  printed  whenever  a  company  level  unit  arrives  at 
the  objective  specified  in  his  operations  order,  if  the  unit  is  moving  in  a 
noncombat  status.  During  the  processing  of  this  event  the  commander  of  the 
unit  will  determine  if  the  company  level  unit  should  be  given  another 
objective  to  meet  the  commanding  unit's  phaseline  requirements.  (See  com¬ 
ments  46,  50,  69,  96,  100.) 

9.  ARTILLERY  CASUALTIES  (100-GUNC0N) 

This  comment  is  printed  whenever  a  unit  suffers  casualties  as  a 
result  of  an  indirect  fire  bombardment  from  an  enemy  artillery  battery. 
Refer  to  the  losses  and  on  hand  columns  of  the  output  for  the  latest  status 
of  the  unit  receiving  the  casualties. 
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10.  ARTY  NET-BUSY  W/BKD  (0-NET0PEN)  See  comment  1. 

11.  ARTY  NET-BUSY  W/MSG  (O-NETOPEN)  See  comment  1. 

12.  ARTY  NET- INOPERABLE  (O-NETOPEN)  See  comment  1. 

13.  ARTY  NET- JAMMED  (O-NETOPEN)  See  comment  1. 

14.  ARTY  NET-OUT/RANGE  (O-NETOPEN)  See  comment  1. 

15.  ARTY  NET  SEC  BREAK  (100-INTRCPT)  See  comment  6. 

16.  ARTY  NET-TRANSMIT  (30-TRNSMIT)  See  comment  7. 

17.  ATKER  CONTINUES  ADV  (100-CBTFIR) 

This  comment  is  printed  whenever  a  company  decides  to  continue 
its  advance  when  in  combat,  even  though  it  has  suffered  casualties,  has 
almost  exhausted  its  ammunition,  or  is  in  danger  of  being  overwhelmed  by 
enemy  forces.  (See  comments  19,  32,  43,  45,  99.) 

18.  AVOID  COMBAT  (100-MZENMUD) 

A  unit  decides  to  avoid  combat  if  it  is  an  artillery  unit,  an 

electronic  warfare  unit,  or  a  headquarters  unit.  When  one  of  these  type 

units  observes  an  enemy  unit  moving  nearby,  and  the  unit  is  close  enough, 
the  artillery  battery,  EW  company,  or  HHC  will  move  away  in  order  to  avoid 
engaging  in  combat.  (See  comments  51,  88.) 

19.  BREAKS  AND  RUNS  (100-CBTFIR) 

This  comment  is  printed  when  a  unit  decides  not  to  continue  com¬ 
bat  and  attempts  to  flee  from  combat  as  quickly  as  possible.  This  does  not 

prevent  enemy  units  from  continuing  to  fire  as  long  as  the  unit  is  within 

range.  (See  comments  17,  32,  43,  45,  99.) 

20.  BTRY  HALTS  TO  FIRE  ( 100-FDCHALT) 

When  a  battalion  fire  direction  center  (FDC)  receives  an  artil¬ 
lery  request,  it  considers  whether  or  not  any  of  the  batteries  should  stop 
to  provide  fire  support.  The  FDC  uses  the  backlog  of  requests  on  hand  and 
the  relative  locations  of  the  batteries  as  guidelines  in  choosing  whether 
to  stop  a  unit  which  is  road  marching.  This  comment  is  printed  when  a 
battery  is  chosen  to  stop  and  fire.  (See  comments  21,  47,  48,  94,  102, 
103,  104.) 

21.  BTRY  ROAO  MARCH  (100-FDCPACK) 

This  comment  is  printed  when  the  FDC  decides  to  move  an  artillery 
battery  (BTRY)  as  a  result  of  receiving  an  artillery  request.  (See  com¬ 
ments  20,  47,  48,  94,  102,  103,  104.) 
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22.  CAS  CASUALTIES  (100-CASDIE) 

This  comment  is  printed  whenever  a  ground  unit  suffers  casualties 
as  a  result  of  being  attacked  by  enemy  close  air  support  (CAS).  Refer  to 
the  losses  and  on  hand  columns  of  the  output  for  the  latest  status  of  the 
unit  receiving  the  casualties. 

23.  CAS  INEFFECTIVE  (100-CASDIE) 

This  comment  is  printed  when  close  air  support  (CAS)  does  not 
cause  any  casualties  to  enemy  forces.  When  a  unit  is  attacked  by  CAS, 
either  this  comment  or  comment  22  is  printed. 

24.  CAS  NET-BUSY  W/BKD  (O-NETOPEN)  See  comment  1. 

25.  CAS  NET-8USY  W/MSG  (O-NETOPEN)  See  comment  1. 

26.  CAS  NET-INOPERABLE  (O-NETOPEN)  See  comment  1. 

27.  CAS  NET- JAMMED  (O-NETOPEN)  See  comment  1. 

28.  CAS  NET-OUT/RANGE  (O-NETOPEN)  See  comment  1. 

29.  CAS  NET  SEC  BREAK  (100-INTRCPT)  See  comment  6. 

30.  CAS  NET-TRANSMIT  (30-TRNSMIT)  See  comment  7. 

31.  CBT  SPD  OUT  OF  RANGE  (100-CBTSPD) 

This  comment  is  printed  when  a  company's  combat  speed  first  gets 
out  of  a  prescribed  range. 

32.  CEASE  FIRE  AND  HOLD  (10-CBTFIR) 

This  comment  is  printed  when  a  unit  runs  low  on  ammunition  and 
decides  to  hold  its  position.  (See  comments  17,  19,  43,  45,  99.) 

33.  COMBAT  ADVANCE  ( 100-H0WSM0V) 

This  comment  is  printed  whenever  a  unit  in  combat  advances  into  a 
hex  toward  its  objective.  Note  that  when  a  defending  unit  is  moving  away 
from  attacking  enemy  units,  toward  its  given  objective,  it  is  considered  to 
be  advancing,  not  retreating,  since  it  is  moving  in  its  intended  direction. 
(See  comment  35. ) 

34.  COMBAT  LOSS  ( 100-WARACES) 

This  comment  is  printed  when  a  unit  loses  forces  as  a  result  of 
direct  ground  fire.  Refer  to  the  losses  and  on  hand  columns  of  the  output 
to  ascertain  the  present  status  of  the  unit. 
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35.  COMBAT  RETREAT  ( lOO-HOWSMOV) 

This  comment  is  printed  when  a  unit  is  forced  away  from  its 
intended  hex  as  a  result  of  losing  forces  in  combat.  At  the  present  time 
this  message  is  only  applicable  to  attacking  units  which  are  actually 
retreating  away  from  their  intended  objective.  (See  comment  33.) 

36.  COM  NET-BUSY  W/BKD  (O-NETOPEN)  See  comment  1. 

37.  COM  NET-BUSY  W/MSG  (O-NETOPEN)  See  comment  1. 

38.  COM  NET-INOPERABLE  (O-NETOPEN)  See  comment  1. 

39.  COM  NET- JAMMED  (O-NETOPEN)  See  comment  1. 

40.  COM  NET-OUT/RANGE  (O-NETOPEN)  See  comment.  1. 

41.  COM  NET  SEC  BREAK  ( 100- INTRCPT)  See  comment  6. 

42.  COM  NET-TRANSMIT  (30-TRNSMIT)  See  comment  7. 

43.  CONTINUE  COMBAT  (100-CBTFIR) 

This  comment  is  printed  when  a  unit  decides  to  continue  in  combat 
despite  casualties  that  the  unit  has  suffered.  (See  comments  17,  19,  32, 
45,  99.) 

44.  COURIER  DELIVERY  (0-DETMSG) 

This  comment  is  printed  when  a  unit  dispatches  a  courier  to 
deliver  a  message  that  it  has  been  unable  to  transmit  to  the  intended 
receiver  over  any  of  its  communication  nets. 

45.  DISENGAGE-NO  AMMO  (100-MUZCMBT) 

This  comment  refers  to  the  actions  taken  by  a  unit  when  it 
effectively  has  no  more  ammunition  and  decides  to  disengage  from  combat,  or 
at  least  attempt  to  disengage.  (See  comments  17,  19,  32,  43,  99.) 

46.  EXECUTE  NEXT  PHASE  ( 100-MUZAMOV) 

This  comment  is  printed  when  a  unit  arrives  at  an  intermediate 
objective  and  decides  to  continue  on  toward  the  next  objective,  whether  it 
be  its  final  objective  or  another  intermediate  one.  The  unit  is  in  a  non¬ 
combat  move  situation  at  this  time,  either  moving  cross  country  or  moving 
along  a  road.  (See  comments  8,  50,  69,  96,  100.) 

47.  FDC  OVERLOADED  (100-F0CPASS) 

This  comment  is  printed  whenever  a  fire  direction  center  (FDC) 
has  too  many  artillery  requests  backlogged  to  effectively  handle  them  all. 
(See  comments  20,  21,  48,  94,  102,  103,  104.) 


48.  FIRED  OUT-ROAD  MARCH  (100-GUNBN) 

This  comment  is  printed  when  a  battery  finishes  a  fire  mission 
and  initiates  a  road  march  to  a  better  position,  or  to  keep  a  proper  dis¬ 
tance  from  the  engaged  maneuver  units.  (See  comments  20,  21,  47,  94,  102, 
103,  104.) 

49.  FOUND  NO  ARTY  SPT  (55-ASKCONV,  ASKIND) 

This  comment  is  printed  when  a  unit  engaged  in  combat  decides  it 
needs  artillery  support  but  finds  it  has  noJ  artillery  unit  assigned  to 
support  it. 

50.  HOLD  AND  OIG  IN  (100-MUZAM0V) 

This  comment  is  printed  when  a  company  level  unit  arrives  at  an 
objective,  whether  it  be  a  final  objective  or  intermediate  one,  and  the 
commander  of  the  company  decides  to  keep  the  unit  in  that  position  because 
the  commander's  overall  objectives  have  been  met,  at  least  temporarily. 
(See  comments  8,  46,  69,  96,  100.) 

51.  IGNORES  ATK/RETREATS  (2Q-MDIRATK) 

This  comment  is  printed  when  a  company  is  retreating  away  from 
combat  and  is  attacked  by  another  unit.  The  retreating  company  ignores 
this  attack  also  and  continues  to  retreat.  This  comment  is  generally 
printed  when  an  arty  unit,  EW  company,  or  HQ  company  is  attacked  while  it 
is  trying  to  get  away  from  an  enemy  unit  it  had  previously  seen.  (See 
comments  18,  88.) 

52.  INITIATE  COMBAT  ( 100-G0T0WAR) 

This  comment  is  printed  when  a  unit  presently  in  non-combat 
status  decides  to  engage  in  combat. 

53.  INTEL  NET-BUSY  W/BKD  (0-NET0PEN)  See  comment  1. 

54.  INTEL  NET-BUSY  W/MSG  (0-NET0PEN)  See  comment  1. 

55.  INTEL  NET- INOPERABLE  (0-NET0PEN)  See  comment  1. 

56.  INTEL  NET- JAMMED  (0-NET0PEN)  See  comment  1. 

57.  INTEL  NET-OUT/RANGE  (0-NET0PEN)  See  comment  1. 

58.  INTEL  NET  SEC  8REAK  (100-INTRCPT)  See  comment  6. 

59.  INTEL  NET-TRANSMIT  (30-TRNSMIT)  See  comment  7. 


60.  INTERCEPTS  ADMIN  NET  (60-INTRCPT) 

This  comment  is  printed  when  an  enemy  listening  unit  intercepts 
a  message  being  transmitted  over  an  administrative  net.  The  general  form 
of  this  type  comment  is: 

INTERCEPTS  "net  type" 

The  possible  net  types  are  the  same  as  those  listed  under  comment  1.  The 
comment  immediately  preceeding  this  one  specifies  the  type  of  message 
intercepted  and  which  unit  was  sending  it.  (See  comment  89.) 

61.  INTERCEPTS  ARTY  NET  (60-INTRCPT)  See  comment  60. 

62.  INTERCEPTS  CAS  NET  (60-INTRCPT)  See  comment  60. 

63.  INTERCEPTS  COM  NET  (60-INTRCPT)  See  comment  60. 

64.  INTERCEPTS  INTEL  NET  (60-INTRCPT)  See  comment  60. 

65.  JAMMER  TURNED  OFF  (100-JAMON) 

This  comment  is  printed  when  a  jamming  unit  turns  off  his  jamming 
equipment.  This  will  occur  at  the  time  specified  by  the  user  in  the  inter¬ 
active  jamming  order. 

66.  JAMMER  TURNED  ON  (100-JAMON) 

This  comment  is  printed  when  a  jamming  unit  turns  on  his  jamming 
equipment.  This  will  occur  at  the  time  specified  by  the  user  in  the  inter¬ 
active  jamming  order. 

67.  KILLED  IN  ACTION  ( 100-NAYDETH) 

This  comment  is  printed  when  a  company  is  rendered  combat  in¬ 
effective  due  to  casualty  losses.  Usually  just  prior  to  this  comment  will 
be  either  a  CAS  CASUALTIES,  COMBAT  LOSS,  or  ARTILLERY  CASUALTIES  comment. 

68.  NET  FREQ  IS  0  (100-JAMCHK) 

This  comment  serves  only  as  a  debug  message. 

69.  NONCOMBAT  MOVE  (35-HEXMOVE) 

This  comment  is  printed  when  a  unit  not  engaged  in  combat  moves 
from  one  hex  to  another.  (See  comments  8,  46,  50,  96,  100.) 

70.  NUDET  ######  (100-GUNNUC) 

This  comment  shows  the  hex  location  of  a  nuclear  detonation. 
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71.  PONDER  ARTY  REQ  ( lOO-MUSEOUT) 

This  comment  is  printed  wnen  a  unit  is  about  to  ponder  a  request 
for  artillery  support. 

72.  PONDER  CAS  REQ  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  a  request 
for  close  air  support. 

73.  PONDER  COMBAT  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  a  subordi¬ 
nate's  combat  situation.  In  particular,  such  pondering  is  triggered  when  a 
subordinate  in  combat  does  not  fire  for  some  reason,  has  run  out  of  ammuni¬ 
tion,  or  moves  at  a  speed  outside  a  prescribed  range.  (See  comments  17, 
19,  31 ,  32,  43,  45,  99.  ) 

74.  PONDER  ENEMY  ATK  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  a  direct 
fire  attack  on  one  of  its  subordinate,  company  level  units. 

75.  PONDER  ENEMY  MOVE  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  an  obser¬ 
vation  of  nearby  enemy  movement. 

76.  PONDER  INTELL  RPT  ( lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  an  intel¬ 
ligence  message  which  has  been  received.  (See  comments  83,  84.) 

77.  PONDER  MOVEMENT  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponder  a  subordi¬ 
nate's  arrival  at  his  objective  without  any  further  operations  orders. 
(See  comments  46,  50,  100.) 

78.  PONDER  NEW  ORDER  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  command  unit  is  about  to  ponder  a 
new  operations  order  which  has  been  received.  (See  comment  95.) 

79.  PONDER  PLAN  (lOO-MUSEOUT) 

This  comment  is  printed  when  a  company  level  unit  is  about  to 
ponder  the  planning  of  a  new  operation  specified  in  new  orders.  (See 
comment  97. ) 


30.  PONDER  STATUS  RPT  ( 1 00-MUSECUT) 

This  comment  is  printed  when  a  unit  is  about  to  ponaer  a  status 
report  which  has  been  received  from  a  subordinate.  (See  comment  98.) 

81.  PRESENT  STATUS  (100-ECH0UT) 

When  a  timeout  is  scheduled,  the  status  of  the  units  in  tne 
scenario  is  printed  out  and  this  comment  refers  to  a  unit's  present  status. 

The  same  comment  is  used  for  both  company  level  units  and  command  units  at 
a  higher  echelon. 

82.  PROCESS  CAS  REQUEST  (100-CASREQ) 

This  comment  is  printed  when  the  corps  DASC  (Direct  Air  Support 
Center)  processes  a  request  from  a  maneuver  unit  for  close  air  support. 

83.  REC  BN-LEVEL  INTELL  (100-MINTLHI) 

This  comment  is  printed  when  a  command  unit  receives  an  intelli¬ 
gence  message  concerning  a  battalion  level  enemy  unit. 

84.  REC  CO-LEVEL  INTELL  ( 100-MINTL0W) 

This  comment  is  printed  when  a  command  unit  receives  an  intelli¬ 
gence  message  concerning  a  company  level  enemy  unit. 

85.  REQ  CLOSE  AIR  SPT  (100-ASKCAS) 

This  comment  is  printed  when  a  unit  decides  to  request  close  air 
support  as  a  result  of  losses  it  has  taken  in  combat. 

86.  REQ  NUKE  ARTY  (100-ASKNUKE) 

This  comment  is  printed  when  a  company  level  unit  requests  a 
nuclear  fire  mission  against  an  enemy  unit. 

87.  REQUEST  ARTY  (30-ASKC0NV,ASKIND) 

This  comment  is  printed  when  a  unit  requests  conventional  artil¬ 
lery  fires  on  an  enemy  company  level  unit. 

88.  RETREATS  FROM  ENEMY  (50-MZENMU0) 

This  comment  is  printed  when  a  company  level  unit,  which  is  not 
an  HHC,  artillery  battery,  or  EW  company,  which  is  already  in  a  panic  mode, 
sees  a  nearby  enemy  unit.  The  company  level  unit  will  continue  to  retreat 
from  the  conflict.  (If  the  unit  is  not  in  a  panic  mode,  it  will  then  con-  , 

sider  whether  or  not  to  engage  the  enemy  unit  in  combat.)  (See  comments  i 

18,  51.)  1 
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89.  SENDS  ARTV  REQUEST  (6C-INTRCPT) 

This  comment  is  printed  when  artillery  support  request  message 
is  intercepted  by  the  enemy.  The  remaining  information  on  this  Mne  of 
output  refers  to  the  unit  sending  the  message.  The  general  form  of  this 
type  comment  is: 

SENDS  "message  type" 

There  are  5  possible  message  types: 

ARTY  REQUEST  Artillery  support  request 

CAS  REQUEST  Close  air  support  request 

INTELL  REPORT  Intelligence  report 

OP  ORDER  Operations  order 

STATUS  REPORT  Unit  status  report 

The  comment  immediately  following  this  one  specifies  the  type  of  net  on 
which  the  message  was  sent  and  which  enemy  unit  intercepted  it.  (See 
comment  60.  ) 

90.  SENDS  CAS  REQUEST  (60-INTRCPT)  See  comment  89. 

91.  SENDS  INTELL  REPORT  (60-INTRCPT)  See  comment  89. 

92.  SENDS  OP  ORDER  (60-INTRCPT)  See  comment  89. 

93.  SENDS  STATUS  REPORT  (60-INTRCPT)  See  comment  89. 

94.  SHORT  ON  AMMO  ( 10Q-GUNBTRY) 

This  comment  is  printed  when  an  artillery  battery  runs  low  on 
ammunition  and  cannot  fire  an  artillery  request.  (See  comments  20,  21,  47, 
48,  102,  103,  104.) 

95.  STARTING  TO  PLAN  OPN  ( 100-MZNEW0R) 

When  a  command  unit  receives  an  operations  order  and  decides  to 
plan  an  operation  for  his  subordinates,  this  comment  is  printed.  (See  com¬ 
ment  97.  ) 

96.  START  N0NCM8T  MOVE  (100- PARADE) 

When  a  company  level  unit,  which  has  been  stopped,  and  is  not  in 
combat  at  the  present  time,  starts  moving,  this  comment  is  printed.  (See 
comments  8,  46,  50,  69,  100.) 

97.  START  OF  PHASE  ( 100-MUZPLAN) 

As  a  result  of  planning  an  operation  this  comment  is  printed  for 
the  company  level  units  that  the  commander  directly  supervises.  (See  com¬ 
ment  95. ) 
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98.  STATUS  RPT  RECEIVED  (45-MSTRPT) 

This  comment  is  printed  when  a  commander  receives  a  status  report 
from  one  of  his  subordinates. 

99.  STOP  AND  OIG  IN  (100-C8TFIR) 

When  a  unit  in  combat  does  not  fire  for  some  reason,  does  not 
break  and  run,  cannot  see  any  nearby  enemy  units,  and  is  defending,  then 
the  unit  will  get  out  of  combat  and  set  up  a  defensive  position  at  its  cur¬ 
rent  location,  and  this  message  is  printed.  (See  comments  17,  19,  32,  A3, 
45.  ) 

100.  STOPPED  AT  PHASELINE  ( 1 00-MUZAM0V) 

When  a  unit  on  the  attack  reaches  the  phaseline  that  his  com¬ 
mander  has  been  told  to  attain,  the  unit  will  stop  and  this  comment  is 
printed.  (See  comments  8,  46,  50,  69,  96.) 

101.  TRY  ALTERNATE  NET  (0-ESTLINK) 

This  comment  is  printed  when  a  unit  tries  to  send  a  message  on  an 
alternate  net  because  it  can't  get  through  on  the  primary  net. 

102.  WILL  NOT  CATCH  UP  ( 100-FDCM0VE) 

If  an  artillery  battalion  fire  direction  center,  in  support  of  an 
attacking  force,  decides  not  to  move  any  batteries  because  they  are  already 
in  proper  position,  this  comment  is  printed.  (See  comments  20,  21,  47,  48, 
94,  103,  104. ) 

103.  WILL  NOT  MOVE  8TRY  (10-FDCM0VE) 

If  an  FDC,  in  support  of  either  an  attacking  force  or  a  defending 
force,  decides  not  to  move  any  batteries  because  too  many  are  already 
moving,  this  comment  is  printed.  (See  comments  20,  21,  47,  48,  94,  102, 

104. ) 

104.  WILL  NOT  ROAD  MARCH  ( 100-FDCM0VE) 

If  an  FDC,  in  support  of  a  defending  force,  decides  not  to  move 
any  batteries  because  they  are  already  in  proper  position,  then  this 
comment  is  printed.  (See  comments  20,  21,  47,  48,  94,  102,  103.) 

105.  ZERO  STATION  ( 100-NET0PEN) 

This  comment  serves  only  as  a  debug  message. 

106.  ZERO  TRANS  TIME  ( 100-TRNSMIT) 

This  comment  serves  only  as  a  debug  message. 
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APPENDIX  C 
UQiL  GRAMMAR 


C.l  INTRODUCTION 

This  appendix  provides  a  brief  description  of  the  structure  or 
grammar  of  the  User  Oriented  Input  Language  (UOIL).  This  language  was 
developed  for  the  METRIC  family  of  simulations  to  enable  the  user  to  des¬ 
cribe  the  un^ts  comprising  the  combat  scenario  with  English-like  sentences. 
A  general  overview  of  UOIL,  along  with  a  typical  input  example,  is  pre¬ 
sented  i n  Section  2. 

C.2  GRAMMAR  RULES 

At  the  end  of  this  section  is  a  set  of  rules  which  abstractly 
define  UOIL.  The  rules  are  presented  in  the  well-known  BNF  (Backus-Naur 
Form)  used  by  computer  scientists  to  define  languages. 

A  BNF  definition  of  a  language  is  given  in  terms  of  the  struc¬ 
tures  which  make  up  the  language.  A  structure  is  identified  by  enclosing 
the  name  of  the  structure  between  the  symbols  <  and  >.  For  example,  a 
sentence  may  be  identified  by  writing  <  SENTENCE  >.  BNF  defines  higher 
level  structures  in  terms  of  lower  level  structures.  For  example,  to 
indicate  that  a  sentence  consists  of  a  subject  followed  by  a  predicate,  one 
could  write 

<  SENTENCE  >:  =  <  SUBJECT  >  <  PREDICATE  >. 

Sometimes  there  are  a  number  of  possible  ways  to  form  a  structure,  and  in 
this  case  the  symbol  |  is  used  to  indicate  "or".  If,  for  example,  the  sub¬ 
ject  of  a  sentence  is  always  either  a  noun  or  a  pronoun,  then  one  could 
write 

<  SUBJECT  > :  =  <  NOUN  >  I <  PRONOUN  >. 

At  some  point  lower  level  structures  must  be  defined  in  terms  of  the  actual 
words  or  symbols  that  appear  in  the  language.  These  are  written  without 
the  symbols  <  and  >  For  example,  if  the  only  pronouns  allowed  in  the 
language  are  he,  she,  and  it,  one  could  write 

<  PRONOUN  > :  =  HE|SHE|lT. 
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When  using  UOIL,  one  should  be  aware  of  the  following  points: 

(1)  Only  one  UOIL  sentence  is  permitted  per  card; 

(2)  The  format  on  each  card  is  free;  i.e.,  the  sentence  may  be 
located  anywhere  on  the  card.  (It  is  convenient  to  use 
indentation  to  highlight  levels  of  command); 

(3)  Spaces  (represented  by  A)  are  required  between  words; 

(4)  A  period  is  required  at  the  end  of  each  sentence. 


C.  3  UOIL  GRAMMAR 


<S> 


<ST0RY> 

<SENTENCE> 

<C2STMT> 

<L0CSTMT> 

<MATRLSTMT> 

<MATPHR1> 

<MATPHR> 

<UNITDESC> 

<VERBCOMMANO> 

<C0L0R> 

<SIDE> 


<ST0RY>  EOR  (EOR  is  an  end  of  record  marker.) 

(<S>  is  the  goal  symbol  of  the 
grammar. ) 

<SENTENCE>  |  <ST0RY>  <SENTENCE> 

<C2STMT> .  |  <L0CSTMT>.  |  <MATRLSTMT> . 

<C0L0R>  I  <SIDE>  |  <NATIONALITY> | 

<UNITDESC>  A  <VER8C0MMAND>  A  <UNITDESC> 

<UNITDESC>  A  IS  A  AT  A  HEX  A  <NUMBER>  A 
<UNITDESC>  A  HAS  A  <MATPHR1> 

<MATPHR>  |  <MATPHR1>  ,  <MATPHR> 

<NUMBER>  A  <MATITEM>  | 

<NUMBER>  A  <MATITEM>  A  OF  A  TYPE  A  <NUMBER>  A 
<NUMBER>  A  <UNITTYPE> 

C  |  CMOS  !  COMMANDS 

BLUE  I  RED 

NATO  |  WP  |  PACT 


(Note  that  in  the  following  definitions,  an  underscored  portion  of  a  word 


is  a  valid  abbreviation.) 


The  following  nationalities  are  permitted  (grouped  by  country): 
<NATIONALITY>  :  =  US  I  GB ,  UK,  or  BR  j  WGR,  BRD,  GE,  or  FRG  |  DANISH | 

DUTCH  or  NL  |  ITALIANI  FRENCH |BE LG  |  CAN  |  RUSSIAN, 

SO ,  or  SU  |  EGR  or  DDR  I  CZECH  |  HUNG  |  POLISH  |  RUM  or 
RO 
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<NUMBER> 


:  =  Any  integer.  For  hexes,  this  must  be  a  valid  hex 

address.  When  associated  with  a  <UNITTYPE>  it  is  the 
unit  number;  e.g.  ,  for  5th  CORPS,  <NUMBER>  :=  5.  For 
material  items  (<MATITEM>)  it  is  the  quantity  of  that 
material . 

<MATITEM>  :  =  INFANTRY,  APCS,  or  ATUS I  TANKS  |  TUBES  |  ROCKETS | 

ROUNDS |  AIRNUKES 1  GROUNDNUKES |  RADIOS 
<UNITTYPE>  Unit  types  are  displayed  by  level.  Units  command 

other  units  of  a  lower  level,  and  every  unit  must 
command  at  least  one  level  3  unit.  Only  level  3  units 
may  have  material  or  a  location.  Units  above-  this 
level  derive  their  positions  and  material  by  aggre¬ 
gating  their  subordinates'  positions  and  material. 

LEVEL  PERMISSIBLE  UNIT  TYPES 

7  CORPS,  CAA,  MRCORPS ,  ARTYCORPS,  ARMORCORPS,  TA, 
AGCORPS,  AGCAA ,  AGTKA 

6  DIV,  ARTYDIV,  CORPSARTY,  CORARTY,  AGMISLGRP , 
AGCORARTY,  AGARTYDIV,  COSCOM,  MECHDIV,  MRDIV, 
AGDIV,  AGINFDIV,  AGMECHDIV,  AGABNDIV,  AGMTNDIV, 
AGMRDIV,  AGCAA,  AIRCAVGRP,  ARMORDIV,  ARMDIV, 
TKDIV,  AG ARMDIV,  AGTKDIV,  AGTKA,  AGCORPSHQ, 
AGCAAHQ,  AGTKAHQ 

5  BOE ,  RGT,  DISCOM,  ARTYBDE,  DIVARTYGP,  ARTYRGT, 
DIVARTY,  MISLBDE,  AGBDE,  RECRGT,  ACR,  AGCAVBDE, 
AGABNRGT ,  MECHBDE,  MRRGT,  AGINFBDE,  AGMECHBDE, 
AGMRRGT ,  ARMORBDE,  ARMBDE ,  TKRGT,  AGARMBDE, 
AGTKRGT 

4  BN,  SQN,  SQDN,  ARTYBN,  MRLBN,  MISLBN,  RECBN,  ACS, 
AIRCAVTF,  MECHBN,  MRBN,  ARMORBN ,  ARMBN,  TKBN 
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CO,  BTY,  BTY152,  BTY130,  BTY122,  8TRY,  HJBTY , 
LANCEBTY,  BTY203,  BTY105,  BTY175,  BTY155,  PROGBTY. 
SCUDBTY,  MRLBTY ,  RECCO,  ACT,  MRCO.  MECCO,  MCSCO, 
AIRRFLTM,  AIRWPNTM,  ARMCO ,  TKCO,  AACSOCO,  HHB . 
HHC ,  HHT,  CORHQFWO,  CORHQREAR,  CORHQALT. 
CORHQMAIN,  ARMYHQFWD,  ARMYHQREAR,  ARMYHQALT , 
ARMYHQMAIN,  DIVHQFWD,  DIVHQREAR,  DIVHQALT, 
DIVHQMAIN,  BOEHQFWD,  BOEHQREAR,  BDEHOALT. 
BOEHQMAIN,  RGTHQFWD,  RGTHQREAR,  RGTHQAlT, 
RGTHQMAIN 
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12  cy  ATTN:  OD 

ATTN: 

CJ-P-G 

ATTN: 

DJ-AM-SM 
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DEPARTMENT  OF  DEFENSE  (Continued) 


U.S.  National  Military  Representative 
SHAPE 

ATTN:  U.S.  Documents  Officer 

Undersecretary  of  Defense  for  Rsch.  A  Engrg. 
ATTN:  Tactical  Warfare  Programs 
ATTN:  Strategic  &  Space  Systems  (OS) 
ATTN:  Research  A  Adv.  Tech. 

WWMCCS  System  Engineering  Org. 

ATTN:  WWMCCS/SEE 


DEPARTMENT  OF  THE  ARMY  (Continued) 


Commander-in 

-Chief 

U.S.  Army  Europe  and  Seventh  Army 

ATTN: 

ODCSE-E  AEAGE 

ATTN: 

DCSOPS-AEAGB 

ATTN: 

DCSOPS-AEAGD-MM 

ATTN: 

DCSOPS-AEAGC-DSW 

ATTN: 

DCSOPS-AEAGC-O 

U.S.  Army  Materiel  Sys.  Analysis  A 

ATTN: 

DRXSY-DS 

ATTN: 

DRXSY-S 

DEPARTMENT  OF  THE  ARMY 

Asst,  Chief  of  Staff  for  Intelligence 
Department  of  the  Army 
ATTN:  DAMI-FI 

Atmospheric  Sciences  Laboratory 
U.S.  Army  Electronics  R&O  Conmand 
ATTN:  DELAS-AS 

Deputy  Chief  of  Staff  for  Ops.  A  Plans 
Department  of  the  Army 
ATTN:  DAMO-RQC 
ATTN :  DAMO-ODW 
ATTN:  DAMO-SSP 
ATTN:  OAMO-ZO 

Deputy  Chief  of  Staff  for  Rsch.,  Dev.,  A  Acq. 
Department  of  the  Army 
ATTN:  DAMA-CSS-N 

ATTN:  Advisor  for  RDA  Analysis,  M.  Gale 


U.S.  Army  Missile  R&D  Command 
ATTN:  DRSMI-YDR 

U.S.  Army  Nuclear  A  Chemical  Agency 
ATTN:  Library  for  MONA-WED 
ATTN:  Library  for  MONA-SAL 
ATTN:  Library 

U.S.  Army  Satellite  Conn.  Agency 
ATTN:  TACSAT  Office 
ATTN:  DRCPM-SC-11 

U.S  Army  TRAOOC  Systems  Analysis  Activity 
ATTN:  ATAA-TAC 

U.S.  Army  Training  and  Doctrine  Cmd. 

ATTN:  Technical  Library 
ATTN:  ATORI-OP-SD 

U.S.  Army  War  College 
ATTN:  Library 


Harry  Diamond  Laboratories 
Department  of  the  Army 
ATTN:  DELHO-N-RBA 
ATTN:  DELHD-N-CO 
ATTN:  DELHD-N-P 
ATTN:  DELHD-N-RBH 
ATTN:  DELHD-I-TL 
2  cy  ATTN:  DELHD-N-EM 


Multi  Service  Communications  Systems 
Department  of  the  Army 

ATTN:  DRCPM-MSCS-APB,  M.  Francis 


V  Corps 

Department  of  the  Army 
ATTN :  AETVGB 
ATTN:  AETVCE 
ATTN:  AETVGC 

VII  Corps 

Department  of  the  Army 
ATTN:  AETSGB-0 
ATTN:  AETSCE 
ATTN:  AETSGC 


U.S.  Army  Ballistic  Research  Labs 
ATTN:  CAL 
ATTN :  TBL 
ATTN:  DRDAR-VL 


DEPARTMENT  OF  THE  NAVY 

Command  &  Control  Programs 
Department  of  the  Navy 
ATTN:  OP  941 


U.S.  Army  Comb.  Arms  Combat  Dev.  Acty 
ATTN:  ATCA-CFT 
ATTN:  ATCA-CA 
ATTN:  ATCA-CO 

U.S.  Army  Cmd.  A  General  Staff  College 
ATTN:  ATSW-TA-D 

U.S.  Army  Comnunications  Sys.  Agency 
ATTN:  CCM-AD-LB 

U.S.  Army  Concepts  Analysis  Agency 
ATTN:  605/606 

U.S.  Army  Electronics  Rsch.  &  Dev.  Command 
ATTN:  ORCPM-ATC 
ATTN:  DRCPM-TDS-SD 


Naval  Ocean  Systems  Center 

ATTN:  Research  Library 

Naval  Surface  Weapons  Center 
ATTN:  Code  F31 

Office  of  the  Chief  of  Naval  Operations 
ATTN :  OP  96 
ATTN:  OP  604  E/F 
ATTN:  OP  94 

Commander-In-Chief 

U.S.  Atlantic  Fleet 

Department  of  the  Navy 
ATTN:  Code  054 
ATTN:  Code  J-611A 
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DEPARTMENT  OF  THE  NAVY  (Continued) 

Commander- in -Chief 
D.S.  Naval  Forces,  Europe 

ATTN:  N3262  Nuclear  Surety  Officer 

DEPARTMENT  OF  THE  AIR  FflRfF 

Air  Force  Geophysics  Laboratory 
ATTN:  SULL 

Air  Force  Weapons  Laboratory 
ATTN:  SUL 
ATTN:  DYC 

Assistant  Chief  of  Staff,  Intelligence 
Department  of  the  Air  Force 
ATTN:  INAK 

Assistant  Chief  of  Staff 
Studies  &  Analyses 
Department  of  the  Air  Force 
ATTN:  AF/SASC 
ATTN:  AF/SAGF 

Deputy  Chief  of  Staff 
Operations,  Plans  and  Readiness 
Department  of  the  Air  Force 
ATTN:  AFXOK 
ATTN:  AFXOXFM 

Deputy  Chief  of  Staff 
Research,  Development,  8.  Acq. 

Department  of  the  Air  Force 
ATTN:  AFRDQSM 

Electronic  Systems  Division 
Department  of  the  Air  Force 
ATTN:  XRC 

Foreign  Technology  Division 
Air  Force  Systems  Command 
ATTN:  NIIS  Library 

Headquarters  Space  Division 
Air  Force  Systems  Command 
ATTN:  SKA 

Headquarters  Space  Division 
Air  Force  Systems  Command 
ATTN:  YCPC 

Strategic  Air  Command 
Department  of  the  Air  Force 
ATTN :  XPFS 
ATTN:  DC  XT 
ATTN:  NRT 

Tactical  Air  Command 
Department  of  the  Air  Force 
ATTN:  DRA 

Commander-in-chief 

U.S.  Air  Forces  in  Europe 
ATTN:  XPXX 
ATTN:  DOC 


OTHER  GOVERNMENT  AGE NC » 

Central  Intelligence  Agency 
ATTN:  OSI/L'D,  R.  hart 
ATTN:  OSR/SF,  R.  Virgo 
ATTN:  OSR/SEC 

DEPARTMENT  OF  DEFENSE  riiNTRArTOiK 
BOM  Corp. 

ATTN:  Corporate  Library 
ATTN:  W.  Sweeney 
ATTN:  D.  Porter 
ATTN:  R.  Schmidt 

66th  MI  Group 

ATTN :  RDA 

Computer  Sciences  Corp. 

ATTN:  H.  Blank 
ATTN:  Library 

ESL,  Inc. 

ATTN:  Library 
ATTN:  J.  Marshall 

General  Electric  Company— TEMPO 
ATTN:  DASIAC 

General  Electric  Company— TEMPO 
ATTN:  DASIAC 

Institute  for  Defense  Analyses 
ATTN:  D.  Signori 
ATTN:  Classified  Library 

Kaman  Sciences  Corp. 

ATTN:  W.  Long 

R&D  Associates 

ATTN:  R.  Schaefer 
ATTN:  R.  Latter 
ATTN:  R.  Poll 

ATTN:  Technical  Information  Center 
ATTN:  C.  MacDonald 

R&D  Associates 

ATTN:  L.  Delaney 
ATTN:  S.  Cicolani 

RCA  Corp. 

ATTN:  E.  Van  Keuren 

SRI  International 

ATTN:  W.  Jaye 
ATTN:  C.  Shoens 

TRW  Defense  &  Space  Sys.  Group 
ATTN:  R.  Webb 

TRW  Defense  &  Space  Sys.  Group 
ATTN:  J.  Dyche 
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